create-apppaaaul 2.0.34 → 2.0.36
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -3,6 +3,7 @@
|
|
|
3
3
|
- [ ] Configurar sitemap
|
|
4
4
|
- [ ] Configurar plausible
|
|
5
5
|
- [ ] Configurar search-console
|
|
6
|
+
- [ ] Añadir test e2e
|
|
6
7
|
|
|
7
8
|
|
|
8
9
|
|
|
@@ -31,4 +32,92 @@ METHOD:
|
|
|
31
32
|
RULES: No hypotheticals—every finding has file:line evidence. Patches must compile.
|
|
32
33
|
|
|
33
34
|
START: Print top 10 checks you’ll run, then proceed with findings → diffs → verification.
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
Testing con cypress (claude 4.5 + plan + max mode)
|
|
38
|
+
```
|
|
39
|
+
ROLE: Senior AppSec Engineer & QA Automation Lead creating automated Cypress end-to-end tests for a Next.js 15 + TypeScript + Prisma + PostgreSQL + BetterAuth + Resend application running on a custom Linux server.
|
|
40
|
+
|
|
41
|
+
GOAL:
|
|
42
|
+
Build a full Cypress test suite covering both:
|
|
43
|
+
|
|
44
|
+
Core functionality: authentication, database CRUD, API routes, server actions, webhooks, uploads, and email flows.
|
|
45
|
+
|
|
46
|
+
Security validation: ensure no ENV/secret leaks, no XSS, CSRF, SSRF, SQLi, header misconfigurations, caching or data leaks, insecure uploads, or missing authorization checks.
|
|
47
|
+
|
|
48
|
+
✅ METHOD
|
|
49
|
+
|
|
50
|
+
Map the project structure:
|
|
51
|
+
|
|
52
|
+
Identify package.json, next.config.*, middleware.ts, app/**/route.ts, server/actions, prisma/schema.prisma, auth/betterauth config, webhooks/, and uploads/.
|
|
53
|
+
|
|
54
|
+
Generate Cypress tests:
|
|
55
|
+
|
|
56
|
+
Create cypress/e2e/*.cy.ts files organized by feature (auth, API, uploads, webhooks, etc.).
|
|
57
|
+
|
|
58
|
+
Use mocked or test database if needed for integration.
|
|
59
|
+
|
|
60
|
+
Automate:
|
|
61
|
+
|
|
62
|
+
Login/logout/session flows (BetterAuth)
|
|
63
|
+
|
|
64
|
+
CRUD operations via UI and API
|
|
65
|
+
|
|
66
|
+
Webhook and email (Resend) validation
|
|
67
|
+
|
|
68
|
+
CSRF protection via Origin/Referer headers
|
|
69
|
+
|
|
70
|
+
CORS and security header checks
|
|
71
|
+
|
|
72
|
+
Rate limiting and caching behavior
|
|
73
|
+
|
|
74
|
+
Include automated security scanning tests:
|
|
75
|
+
|
|
76
|
+
Secrets Exposure: Detect process.env.(?!NEXT_PUBLIC_) values appearing in client-side responses.
|
|
77
|
+
|
|
78
|
+
XSS: Test any rendering with dangerouslySetInnerHTML or markdown output using injected <script> payloads to ensure sanitization.
|
|
79
|
+
|
|
80
|
+
SQL Injection: Inject common payloads into form fields or query params.
|
|
81
|
+
|
|
82
|
+
SSRF/Open Redirects: Test redirects and user-controlled URLs.
|
|
83
|
+
|
|
84
|
+
Uploads: Validate MIME type, file size, and path traversal protections.
|
|
85
|
+
|
|
86
|
+
Logging/PII: Ensure sensitive info (tokens, emails, passwords) isn’t leaked to console or network responses.
|
|
87
|
+
|
|
88
|
+
Test structure & assertions:
|
|
89
|
+
|
|
90
|
+
Use describe() for each feature/security vector and it() for individual scenarios.
|
|
91
|
+
|
|
92
|
+
Include verification steps for fixes (e.g., assert sanitized HTML or secure headers).
|
|
93
|
+
|
|
94
|
+
Use cy.intercept() for API validation and cy.request() for server responses.
|
|
95
|
+
|
|
96
|
+
🧠 TEST RULES
|
|
97
|
+
|
|
98
|
+
All tests must run with cypress run --browser chrome --headless and pass deterministically.
|
|
99
|
+
|
|
100
|
+
Each test must reference real routes, endpoints, and features—no hypotheticals.
|
|
101
|
+
|
|
102
|
+
Include both UI and API-level tests.
|
|
103
|
+
|
|
104
|
+
Add cy.task() or fixtures for mocking emails, tokens, or DB data.
|
|
105
|
+
|
|
106
|
+
Report results grouped as Functional | Security | Regression.
|
|
107
|
+
|
|
108
|
+
📋 OUTPUT FORMAT
|
|
109
|
+
|
|
110
|
+
“Test Plan Summary” – table of features covered (Functional | Security | Coverage %).
|
|
111
|
+
|
|
112
|
+
“Generated Tests” – Cypress test file paths + code snippets.
|
|
113
|
+
|
|
114
|
+
“Execution Results” – pass/fail summary for each suite.
|
|
115
|
+
|
|
116
|
+
“Next Steps” – recommended refactors or security hardening items.
|
|
117
|
+
|
|
118
|
+
🚀 START
|
|
119
|
+
|
|
120
|
+
Step 1: Print the top 10 Cypress test groups you will generate (by feature or attack vector).
|
|
121
|
+
Step 2: Generate the corresponding *.cy.ts files with full Cypress syntax.
|
|
122
|
+
Step 3: Include explanations for each test’s purpose, expected outcome, and key security checks.
|
|
34
123
|
```
|