Cursor rule

1---
2alwaysApply: false
3---
4 
5# Baseline Security Rules
6 
7## Overview
8These security rules are MANDATORY cross-cutting constraints that apply across all AI-DLC phases. They are not optional guidance — they are hard constraints that stages MUST enforce when generating questions, producing design artifacts, generating code, and presenting completion messages.
9 
10**Enforcement**: At each applicable stage, the model MUST verify compliance with these rules before presenting the stage completion message to the user.
11 
12### Blocking Security Finding Behavior
13A **blocking security finding** means:
141. The finding MUST be listed in the stage completion message under a "Security Findings" section with the SECURITY rule ID and description
152. The stage MUST NOT present the "Continue to Next Stage" option until all blocking findings are resolved
163. The model MUST present only the "Request Changes" option with a clear explanation of what needs to change
174. The finding MUST be logged in `aidlc-docs/audit.md` with the SECURITY rule ID, description, and stage context
18 
19If a SECURITY rule is not applicable to the current project (e.g., SECURITY-01 when no data stores exist), mark it as **N/A** in the compliance summary — this is not a blocking finding.
20 
21### Default Enforcement
22All rules in this document are **blocking** by default. If any rule's verification criteria are not met, it is a blocking security finding — follow the blocking finding behavior defined above.
23 
24### Verification Criteria Format
25Verification items in this document are plain bullet points describing compliance checks. They are distinct from the `- [ ]` / `- [x]` progress-tracking checkboxes used in stage plan files. Each item should be evaluated as compliant or non-compliant during review.
26 
27---
28 
29## Rule SECURITY-01: Encryption at Rest and in Transit
30 
31**Rule**: Every data persistence store (databases, object storage, file systems, caches, or any equivalent) MUST have:
32- Encryption at rest enabled using a managed key service or customer-managed keys
33- Encryption in transit enforced (TLS 1.2+ for all data movement in and out of the store)
34 
35**Verification**:
36- No storage resource is defined without an encryption configuration block
37- No database connection string uses an unencrypted protocol
38- Object storage enforces encryption at rest and rejects non-TLS requests via policy
39- Database instances have storage encryption enabled and enforce TLS connections
40 
41---
42 
43## Rule SECURITY-02: Access Logging on Network Intermediaries
44 
45**Rule**: Every network-facing intermediary that handles external traffic MUST have access logging enabled. This includes:
46- Load balancers → access logs to a persistent store
47- API gateways → execution logging and access logging to a centralized log service
48- CDN distributions → standard logging or real-time logs
49 
50**Verification**:
51- No load balancer resource is defined without access logging enabled
52- No API gateway stage is defined without access logging configured
53- No CDN distribution is defined without logging configuration
54 
55---
56 
57## Rule SECURITY-03: Application-Level Logging
58 
59**Rule**: Every deployed application component MUST include structured logging infrastructure:
60- A logging framework MUST be configured
61- Log output MUST be directed to a centralized log service
62- Logs MUST include: timestamp, correlation/request ID, log level, and message
63- Sensitive data (passwords, tokens, PII) MUST NOT appear in log output
64 
65**Verification**:
66- Every service/function entry point includes a configured logger
67- No ad-hoc logging statements used as the primary logging mechanism in production code
68- Log configuration routes output to a centralized log service
69- No secrets, tokens, or PII are logged
70 
71---
72 
73## Rule SECURITY-04: HTTP Security Headers for Web Applications
74 
75**Rule**: The following HTTP response headers MUST be set on all HTML-serving endpoints:
76 
77| Header | Required Value |
78|---|---|
79| `Content-Security-Policy` | Define a restrictive policy (at minimum: `default-src 'self'`) |
80| `Strict-Transport-Security` | `max-age=31536000; includeSubDomains` |
81| `X-Content-Type-Options` | `nosniff` |
82| `X-Frame-Options` | `DENY` (or `SAMEORIGIN` if framing is required) |
83| `Referrer-Policy` | `strict-origin-when-cross-origin` |
84 
85**Note**: `X-XSS-Protection` is deprecated in modern browsers. Use `Content-Security-Policy` instead.
86 
87**Verification**:
88- Middleware or response interceptor sets all required headers
89- CSP policy does not use `unsafe-inline` or `unsafe-eval` without documented justification
90- HSTS max-age is at least 31536000 (1 year)
91 
92---
93 
94## Rule SECURITY-05: Input Validation on All API Parameters
95 
96**Rule**: Every API endpoint (REST, GraphQL, gRPC, WebSocket) MUST validate all input parameters before processing. Validation MUST include:
97- **Type checking**: Reject unexpected types
98- **Length/size bounds**: Enforce maximum lengths on strings, maximum sizes on arrays and payloads
99- **Format validation**: Use allowlists (regex or schema) for structured inputs (emails, dates, IDs)
100- **Sanitization**: Escape or reject HTML/script content in user-supplied strings to prevent XSS
101- **Injection prevention**: Use parameterized queries for all database operations (never string concatenation)
102 
103**Verification**:
104- Every API handler uses a validation library or schema
105- No raw user input is concatenated into SQL, NoSQL, or OS commands
106- String inputs have explicit max-length constraints
107- Request body size limits are configured at the framework or gateway level
108 
109---
110 
111## Rule SECURITY-06: Least-Privilege Access Policies
112 
113**Rule**: Every identity and access management policy, role, or permission boundary MUST follow least privilege:
114- Use specific resource identifiers — NEVER use wildcard resources unless the API does not support resource-level permissions (document the exception)
115- Use specific actions — NEVER use wildcard actions
116- Scope conditions where possible
117- Separate read and write permissions into distinct policy statements
118 
119**Verification**:
120- No policy contains wildcard actions or wildcard resources without a documented exception
121- No service role has broader permissions than what the service actually calls
122- Inline policies are avoided in favor of managed policies where possible
123- Every role has a trust policy scoped to the specific service or account
124 
125---
126 
127## Rule SECURITY-07: Restrictive Network Configuration
128 
129**Rule**: All network configurations (security groups, network ACLs, route tables) MUST follow deny-by-default:
130- Firewall rules: Only open specific ports required by the application
131- No inbound rule with source `0.0.0.0/0` except for public-facing load balancers on ports 80/443
132- No outbound rule with `0.0.0.0/0` on all ports unless explicitly justified
133- Private subnets MUST NOT have direct internet gateway routes
134- Use private endpoints for cloud service access where available
135 
136**Verification**:
137- No firewall rule allows inbound `0.0.0.0/0` on any port other than 80/443 on a public load balancer
138- Database and application firewall rules restrict source to specific CIDR blocks or security group references
139- Private subnets route through a NAT gateway (not an internet gateway)
140- Private endpoints are used for high-traffic cloud service calls
141 
142---
143 
144## Rule SECURITY-08: Application-Level Access Control
145 
146**Rule**: Every application endpoint that accesses or mutates a resource MUST enforce authorization checks at the application layer:
147- **Deny by default**: All routes/endpoints MUST require authentication unless explicitly marked as public
148- **Object-level authorization**: Every request that references a resource by ID MUST verify the requesting user/principal owns or has permission to access that resource (prevent IDOR)
149- **Function-level authorization**: Administrative or privileged operations MUST check the caller's role/permissions server-side — never rely on client-side hiding
150- **CORS policy**: Cross-origin resource sharing MUST be restricted to explicitly allowed origins — never use `Access-Control-Allow-Origin: *` on authenticated endpoints
151- **Token validation**: JWTs or session tokens MUST be validated server-side on every request (signature, expiration, audience, issuer)
152 
153**Verification**:
154- Every controller/handler has an authorization middleware or guard applied
155- No endpoint returns data for a resource ID without verifying the caller's ownership or permission
156- Admin/privileged routes have explicit role checks enforced server-side
157- CORS configuration does not use wildcard origins on authenticated endpoints
158- Token validation occurs server-side on every request (not just at login)
159 
160---
161 
162## Rule SECURITY-09: Security Hardening and Misconfiguration Prevention
163 
164**Rule**: All deployed components MUST follow a hardening baseline:
165- **No default credentials**: Default usernames/passwords MUST be changed or disabled before deployment
166- **Minimal installation**: Remove or disable unused features, frameworks, sample applications, and documentation endpoints
167- **Error handling**: Production error responses MUST NOT expose stack traces, internal paths, framework versions, or database details to end users
168- **Directory listing**: Web servers MUST disable directory listing
169- **Cloud storage**: Cloud object storage MUST block public access unless explicitly required and documented
170- **Patch management**: Runtime environments, frameworks, and OS images MUST use current, supported versions
171 
172**Verification**:
173- No default credentials exist in configuration files, environment variables, or IaC templates
174- Error responses in production return generic messages (no stack traces or internal details)
175- Cloud object storage has public access blocked unless a documented exception exists
176- No sample/demo applications or default pages are deployed
177- Framework and runtime versions are current and supported
178 
179 
180---
181 
182## Rule SECURITY-10: Software Supply Chain Security
183 
184**Rule**: Every project MUST manage its software supply chain:
185- **Dependency pinning**: All dependencies MUST use exact versions or lock files
186- **Vulnerability scanning**: A dependency vulnerability scanner MUST be configured 
187- **No unused dependencies**: Remove packages that are not actively used
188- **Trusted sources only**: Dependencies MUST be pulled from official registries or verified private registries — no unvetted third-party sources
189- **SBOM**: Projects MUST generate a Software Bill of Materials for production deployments
190- **CI/CD integrity**: Build pipelines MUST use pinned tool versions and verified base images — no `latest` tags in production Dockerfiles or CI configurations
191 
192**Verification**:
193- A lock file exists and is committed to version control
194- A dependency vulnerability scanning step is included in CI/CD or documented in build instructions
195- No unused or abandoned dependencies are included
196- Dockerfiles and CI configs do not use `latest` or unpinned image tags for production
197- Dependencies are sourced from official or verified registries
198 
199---
200 
201## Rule SECURITY-11: Secure Design Principles
202 
203**Rule**: Application design MUST incorporate security from the start:
204- **Separation of concerns**: Security-critical logic (authentication, authorization, payment processing) MUST be isolated in dedicated modules — not scattered across the codebase
205- **Defense in depth**: No single control should be the sole line of defense — layer controls (validation + authorization + encryption)
206- **Rate limiting**: Public-facing endpoints MUST implement rate limiting or throttling to prevent abuse
207- **Business logic abuse**: Design MUST consider misuse cases — not just happy-path scenarios
208 
209**Verification**:
210- Security-critical logic is encapsulated in dedicated modules or services
211- Rate limiting is configured on public-facing APIs
212- Design documentation addresses at least one misuse/abuse scenario
213 
214---
215 
216## Rule SECURITY-12: Authentication and Credential Management
217 
218**Rule**: Every application with user authentication MUST implement:
219- **Password policy**: Minimum 8 characters, check against breached password lists
220- **Credential storage**: Passwords MUST be hashed using adaptive algorithms — never weak or non-adaptive hashing
221- **Multi-factor authentication**: MFA MUST be supported for administrative accounts and SHOULD be available for all users
222- **Session management**: Sessions MUST have server-side expiration, be invalidated on logout, and use secure/httpOnly/sameSite cookie attributes
223- **Brute-force protection**: Login endpoints MUST implement account lockout, progressive delays, or CAPTCHA after repeated failures
224- **No hardcoded credentials**: No passwords, API keys, or secrets in source code or IaC templates — use a secrets manager
225 
226**Verification**:
227- Password hashing uses adaptive algorithms (not weak or non-adaptive hashing)
228- Session cookies set `Secure`, `HttpOnly`, and `SameSite` attributes
229- Login endpoints have brute-force protection (lockout, delay, or CAPTCHA)
230- No hardcoded credentials in source code or configuration files
231- MFA is supported for admin accounts
232- Sessions are invalidated on logout and have a defined expiration
233 
234---
235 
236## Rule SECURITY-13: Software and Data Integrity Verification
237 
238**Rule**: Systems MUST verify the integrity of software and data:
239- **Deserialization safety**: Untrusted data MUST NOT be deserialized without validation — use safe deserialization libraries or allowlists of permitted types
240- **Artifact integrity**: Downloaded dependencies, plugins, and updates MUST be verified via checksums or digital signatures
241- **CI/CD pipeline security**: Build pipelines MUST restrict who can modify pipeline definitions — separate duties between code authors and deployment approvers
242- **CDN and external resources**: Scripts or resources loaded from external CDNs MUST use Subresource Integrity (SRI) hashes
243- **Data integrity**: Critical data modifications MUST be auditable (who changed what, when)
244 
245**Verification**:
246- No unsafe deserialization of untrusted input
247- External scripts include SRI integrity attributes when loaded from CDNs
248- CI/CD pipeline definitions are access-controlled and changes are auditable
249- Critical data changes are logged with actor, timestamp, and before/after values
250 
251---
252 
253## Rule SECURITY-14: Alerting and Monitoring
254 
255**Rule**: In addition to logging (SECURITY-02, SECURITY-03), systems MUST include:
256- **Security event alerting**: Alerts MUST be configured for high-value security events: repeated authentication failures, privilege escalation attempts, access from unusual locations, and authorization failures
257- **Log integrity**: Logs MUST be stored in append-only or tamper-evident storage — application code MUST NOT be able to delete or modify its own audit logs
258- **Log retention**: Logs MUST be retained for a minimum period appropriate to the application's compliance requirements (default: 90 days minimum)
259- **Monitoring dashboards**: A monitoring dashboard or alarm configuration MUST be defined for key operational and security metrics
260 
261**Verification**:
262- Alerting is configured for authentication failures and authorization violations
263- Application log groups have retention policies set (minimum 90 days)
264- Application roles do not have permission to delete their own log groups/streams
265- Security-relevant events (login failures, access denied, privilege changes) generate alerts
266 
267---
268 
269## Rule SECURITY-15: Exception Handling and Fail-Safe Defaults
270 
271**Rule**: Every application MUST handle exceptional conditions safely:
272- **Catch and handle**: All external calls (database, API, file I/O) MUST have explicit error handling — no unhandled promise rejections or uncaught exceptions in production
273- **Fail closed**: On error, the system MUST deny access or halt the operation — never fail open
274- **Resource cleanup**: Error paths MUST release resources (connections, file handles, locks) — use try/finally, using statements, or equivalent patterns
275- **User-facing errors**: Error messages shown to users MUST be generic — no internal details or system information
276- **Global error handler**: Applications MUST have a global/top-level error handler that catches unhandled exceptions, logs them (per SECURITY-03), and returns a safe response
277 
278**Verification**:
279- All external calls (DB, HTTP, file I/O) have explicit error handling (try/catch, .catch(), error callbacks)
280- A global error handler is configured at the application entry point
281- Error paths do not bypass authorization or validation checks (fail closed)
282- Resources are cleaned up in error paths (connections closed, transactions rolled back)
283- No unhandled promise rejections or uncaught exception warnings in application code
284 
285---
286 
287## Enforcement Integration
288 
289These rules are cross-cutting constraints that apply to every AI-DLC stage. At each stage:
290- Evaluate all SECURITY rule verification criteria against the artifacts produced
291- Include a "Security Compliance" section in the stage completion summary listing each rule as compliant, non-compliant, or N/A
292- If any rule is non-compliant, this is a blocking security finding — follow the blocking finding behavior defined in the Overview
293- Include security rule references in design documentation and test instructions
294 
295---
296 
297## Appendix: OWASP Reference Mapping
298 
299<!-- TODO: CRITICAL - This entire OWASP mapping table needs verification. The "2025" edition may not exist; the latest published OWASP Top 10 is 2021. Category IDs (A01-A10), numbering, and names must be validated against the actual published standard before relying on this mapping. -->
300For human reviewers, the following maps SECURITY rules to OWASP Top 10 (2025) categories:
301 
302| SECURITY Rule | OWASP Category |
303|---|---|
304| SECURITY-08 | A01:2025 – Broken Access Control |
305| SECURITY-09 | A02:2025 – Security Misconfiguration |
306| SECURITY-10 | A03:2025 – Software Supply Chain Failures |
307| SECURITY-11 | A06:2025 – Insecure Design |
308| SECURITY-12 | A07:2025 – Authentication Failures |
309| SECURITY-13 | A08:2025 – Software or Data Integrity Failures |
310| SECURITY-14 | A09:2025 – Logging & Alerting Failures |
311| SECURITY-15 | A10:2025 – Mishandling of Exceptional Conditions |
312