.cursorrules (deprecated)

1# Security Best Practices — Cursor Rules
2# Comprehensive rules for writing secure application code
3 
4## Project Context
5You are working on an application where security is a top priority. The codebase must
6protect against common vulnerabilities (OWASP Top 10), handle sensitive data carefully,
7and follow the principle of least privilege. Every code change should be evaluated for
8security implications.
9 
10## Core Principles
11- Defense in depth — multiple layers of security
12- Principle of least privilege — grant minimum necessary access
13- Fail securely — errors should not expose sensitive information
14- Never trust user input — validate and sanitize everything
15- Secure by default — security should not require extra configuration
16 
17## Input Validation
18 
19### Rules
20- Validate ALL input on the server side, regardless of client-side validation
21- Use allowlists (valid values) over denylists (blocked values)
22- Validate type, length, range, and format
23- Use established validation libraries (Zod, Joi, Pydantic)
24- Reject invalid input — don't try to clean or fix it
25 
26### Patterns
27```ts
28// GOOD — strict validation with Zod
29const createUserSchema = z.object({
30  email: z.string().email().max(255),
31  name: z.string().min(1).max(100).regex(/^[a-zA-Z\s'-]+$/),
32  age: z.number().int().min(13).max(150),
33  role: z.enum(['user', 'editor']),  // Allowlist, not freeform string
34});
35 
36// BAD — trusting input
37app.post('/users', (req, res) => {
38  db.query(`INSERT INTO users (name) VALUES ('${req.body.name}')`); // SQL injection!
39});
40```
41 
42## SQL Injection Prevention
43 
44### ALWAYS Use Parameterized Queries
45```ts
46// GOOD — parameterized
47const user = await db.query('SELECT * FROM users WHERE email = $1', [email]);
48 
49// GOOD — ORM (Prisma handles parameterization)
50const user = await prisma.user.findUnique({ where: { email } });
51 
52// BAD — string concatenation
53const user = await db.query(`SELECT * FROM users WHERE email = '${email}'`);
54 
55// BAD — template literals
56const user = await db.query(`SELECT * FROM users WHERE email = '${req.body.email}'`);
57```
58 
59### Rules
60- Never concatenate user input into SQL strings
61- Use ORM query builders or parameterized queries exclusively
62- Validate and type-check input before passing to queries
63- Use stored procedures for complex operations
64- Limit database user permissions to only required operations
65 
66## Cross-Site Scripting (XSS) Prevention
67 
68### Rules
69- Escape all user-generated content before rendering in HTML
70- Use framework auto-escaping (React JSX, Vue templates escape by default)
71- Never use `dangerouslySetInnerHTML` (React) or `v-html` (Vue) with user content
72- Set `Content-Security-Policy` headers to restrict script sources
73- Sanitize HTML if rich text is required (use DOMPurify)
74 
75```tsx
76// SAFE — React auto-escapes
77<p>{userInput}</p>
78 
79// DANGEROUS — raw HTML injection
80<div dangerouslySetInnerHTML={{ __html: userInput }} />
81 
82// If you must render HTML, sanitize first
83import DOMPurify from 'dompurify';
84<div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(userInput) }} />
85```
86 
87### Content Security Policy
88```
89Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; connect-src 'self' https://api.example.com; frame-ancestors 'none';
90```
91 
92## Authentication
93 
94### Password Handling
95- Hash passwords with bcrypt (cost factor 12+) or Argon2id
96- Never store plain-text passwords
97- Never log passwords, even in error messages
98- Enforce minimum password length (8+ characters)
99- Check passwords against breached password databases (Have I Been Pwned API)
100- Implement account lockout after failed attempts (5 attempts, 15-minute lockout)
101 
102```ts
103import bcrypt from 'bcrypt';
104 
105// Hashing
106const SALT_ROUNDS = 12;
107const passwordHash = await bcrypt.hash(password, SALT_ROUNDS);
108 
109// Verification (constant-time comparison built in)
110const isValid = await bcrypt.compare(inputPassword, storedHash);
111```
112 
113### JWT Best Practices
114- Use short expiry times (15 minutes for access tokens)
115- Use refresh tokens (stored in httpOnly cookies) for session extension
116- Include minimal claims — don't put sensitive data in JWTs
117- Validate `iss`, `aud`, and `exp` claims on every request
118- Use RS256 (asymmetric) for distributed systems, HS256 for single-service
119- Store the signing secret in environment variables, never in code
120- Implement token revocation (blacklist or versioned tokens)
121 
122### Session Security
123- Use httpOnly, Secure, SameSite=Strict cookies for session tokens
124- Regenerate session ID after login (prevent session fixation)
125- Set appropriate session timeout (idle and absolute)
126- Invalidate sessions on password change and logout
127 
128## Authorization
129 
130### Rules
131- Check authorization on EVERY request, not just the UI layer
132- Verify resource ownership — don't just check authentication
133- Use role-based access control (RBAC) or attribute-based (ABAC)
134- Implement authorization in middleware, not scattered through handlers
135- Log authorization failures for security monitoring
136 
137```ts
138// GOOD — check ownership
139async function getOrder(req, res) {
140  const order = await Order.findById(req.params.id);
141  if (!order) return res.status(404).json({ error: 'Not found' });
142  if (order.userId !== req.user.id && req.user.role !== 'admin') {
143    return res.status(403).json({ error: 'Forbidden' });
144  }
145  res.json(order);
146}
147 
148// BAD — only checks authentication, not authorization
149async function getOrder(req, res) {
150  const order = await Order.findById(req.params.id);
151  res.json(order); // Any authenticated user can access any order!
152}
153```
154 
155## Sensitive Data Handling
156 
157### Environment Variables and Secrets
158- Never commit secrets to version control
159- Use `.env` files for local development, secret managers for production
160- Add `.env` to `.gitignore`
161- Rotate secrets regularly
162- Use different secrets per environment (dev, staging, production)
163 
164### Data at Rest
165- Encrypt sensitive data in the database (PII, financial data)
166- Use database-level encryption (TDE) or application-level encryption
167- Hash data that only needs verification (passwords, API keys)
168- Mask sensitive data in logs: `email: a****@example.com`
169 
170### Data in Transit
171- Use HTTPS everywhere — no exceptions
172- Use TLS 1.2+ for all service-to-service communication
173- Validate SSL certificates — don't disable verification
174- Use HSTS headers to enforce HTTPS
175 
176## HTTP Security Headers
177```ts
178// Use helmet.js (Express) or set manually
179app.use(helmet());
180 
181// Or set individually:
182// Prevent clickjacking
183res.setHeader('X-Frame-Options', 'DENY');
184// Prevent MIME sniffing
185res.setHeader('X-Content-Type-Options', 'nosniff');
186// Control referrer information
187res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin');
188// Enforce HTTPS
189res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
190// Control permissions
191res.setHeader('Permissions-Policy', 'camera=(), microphone=(), geolocation=()');
192```
193 
194## Rate Limiting
195- Implement rate limiting on all public endpoints
196- Stricter limits on authentication endpoints (login, password reset)
197- Use sliding window or token bucket algorithms
198- Return `429 Too Many Requests` with `Retry-After` header
199- Consider per-user and per-IP rate limits
200 
201## Logging and Monitoring
202- Log all authentication events (login, logout, failures)
203- Log authorization failures
204- Log input validation failures (potential attack probing)
205- Never log passwords, tokens, credit card numbers, or full SSN
206- Include request ID, user ID, IP address, and timestamp in logs
207- Set up alerts for anomalous patterns (brute force, unusual access)
208 
209## Dependency Security
210- Keep dependencies updated — check for known vulnerabilities
211- Run `npm audit` / `pip audit` regularly
212- Use lockfiles (`package-lock.json`, `poetry.lock`) for reproducible builds
213- Review new dependencies before adding (check maintenance, popularity, security record)
214- Pin major versions to avoid unexpected breaking changes
215 
216## Common Pitfalls
217- Trusting client-side validation as the only validation
218- Using MD5 or SHA256 for password hashing (use bcrypt/Argon2)
219- Storing secrets in code or version control
220- Returning detailed error messages in production (stack traces, SQL errors)
221- Not implementing rate limiting on authentication endpoints
222- Using `*` for CORS origins in production
223- Not checking resource ownership after authentication
224- Logging sensitive data (passwords, tokens, PII)
225- Using outdated dependencies with known vulnerabilities
226- Disabling HTTPS or SSL verification for "convenience"
227