AI Coding for Security Engineers

Why Security Engineers Should Care About AI Coding Rules

You are a security engineer. You review code for vulnerabilities, define secure coding standards, and respond to security incidents. Your problem: you can review every PR manually — but you cannot scale. A 20-person engineering team produces 40-60 PRs per week. You catch SQL injection in PR #42. The same pattern reappears in PR #57 from a different developer. Without AI rules: you are playing whack-a-mole with the same vulnerability classes, sprint after sprint. Each fix: a point solution. Each developer: learns individually, slowly.

With AI rules: the AI generates secure code by default. AI rule: 'All database queries use parameterized statements. Never concatenate user input into SQL strings. Use the db.query(sql, params) pattern from our ORM.' Every AI-generated database interaction: parameterized automatically. The SQL injection class: eliminated at the source. The security engineer: reviews for business logic vulnerabilities (authorization, data exposure) instead of basic input handling mistakes. The shift: from catching known vulnerability patterns to focusing on novel security concerns.

The security-specific benefit: AI rules scale security knowledge to every developer, every AI-generated line of code, 24/7. One rule in CLAUDE.md replaces thousands of repeated code review comments. The security team: writes the rules once. Every developer's AI: enforces them in every generated file. The coverage: 100% of AI-generated code follows the security standard, regardless of which developer prompted it.

How AI Rules Create Secure-by-Default Code

Input validation at every boundary: the #1 security rule category. AI rule: 'All API endpoints validate input with zod schemas. All form inputs sanitize with DOMPurify before rendering. All file uploads validate MIME type, size, and filename.' The AI: adds validation to every input boundary automatically. The developer: does not need to remember which validation library to use or which fields to validate. The security engineer: reviews the zod schemas for completeness rather than checking whether validation exists at all. The shift: from 'did they validate?' to 'did they validate correctly?'

Authentication and authorization patterns: AI rule: 'All API routes use the withAuth middleware. Role checks use the checkRole(user, requiredRole) utility. Never check roles with string comparison — use the Role enum. Session tokens: httpOnly, secure, sameSite=strict.' The AI: generates authenticated and authorized endpoints by default. The developer: cannot accidentally create an unprotected endpoint because the AI includes the middleware. The security engineer: reviews the role requirements (should this be admin-only?) rather than checking for missing auth middleware.

Output encoding and XSS prevention: AI rule: 'Never use dangerouslySetInnerHTML. All dynamic content rendered through React JSX (auto-escaped). User-generated content: sanitize with DOMPurify before storage, escape on render. URLs: validate protocol (https only) before rendering as links.' The AI: generates XSS-safe rendering by default. The developer: never renders raw HTML from user input. The security engineer: trusts that the output encoding standard is applied consistently. AI rule: 'Secure-by-default means the AI generates secure code without the developer asking for it. The developer types a prompt. The AI generates code that validates inputs, checks authorization, and encodes outputs — not because the developer requested it, but because the rules require it. Security becomes invisible: always present, never forgotten.'

Preventing OWASP Top 10 with AI Rules

Injection prevention (OWASP #1): beyond SQL injection, injection attacks target OS commands, LDAP queries, and template engines. AI rule: 'Never pass user input to child_process.exec. Use child_process.execFile with explicit argument arrays. Never interpolate user input into template strings processed by template engines.' The AI: generates injection-safe code across all interpreter interfaces, not just SQL. The security engineer: defines the rule once for each injection vector. The AI: applies it everywhere.

Broken access control (OWASP #2): the most common web vulnerability. AI rule: 'All data access functions include a tenantId parameter. Queries must filter by tenantId — never return data across tenants. Use the assertOwnership(user, resource) check before any update or delete operation.' The AI: generates tenant-isolated queries by default. The developer: cannot accidentally expose one tenant's data to another. The multi-tenant isolation: enforced at the query level, not just the API level.

Security misconfiguration (OWASP #5): default configurations are insecure. AI rule: 'CORS: allow only production origins, never wildcard. CSP: default-src self, script-src self. HSTS: max-age 31536000, includeSubDomains. Rate limiting: 100 requests per minute per IP on all public endpoints.' The AI: generates secure configuration defaults. The developer: does not need to research security headers — the rules encode the team's security posture. The security engineer: audits the rules quarterly rather than auditing every deployment. AI rule: 'OWASP Top 10 vulnerabilities are well-known and well-documented. They persist not because developers do not know about them, but because developers forget to apply the prevention. AI rules: eliminate forgetting. The prevention is applied automatically, every time, in every file.'

Security Engineer Workflow with AI Rules

Writing security rules: the security engineer's new superpower. Instead of reviewing 50 PRs per week for the same vulnerability patterns: write one rule that prevents the pattern in all AI-generated code. The time investment: 30 minutes to write and test the rule. The return: the vulnerability pattern eliminated from all future code. The security engineer: shifts from reactive (finding vulnerabilities in reviews) to proactive (preventing vulnerabilities at generation time).

Security rule testing: how do you verify that an AI rule actually prevents a vulnerability? Write a prompt that should trigger the vulnerable pattern. Verify the AI generates the secure alternative. Example: prompt 'create an API endpoint that searches users by name.' Expected output: parameterized query with the search term. If the AI generates string concatenation: the rule is not effective — refine the wording. The testing: straightforward and deterministic.

Incident-to-rule pipeline: when a security incident occurs, the remediation includes a new AI rule. Incident: reflected XSS via unsanitized user profile fields. Fix: sanitize the specific field. Rule: 'All user-generated text fields sanitize on input with DOMPurify and escape on output.' The incident: fixed once. The rule: prevents the same class of vulnerability in all future code. The incident-to-rule pipeline: transforms security incidents from recurring problems into permanent improvements. AI rule: 'Security engineers who write AI rules are force-multipliers. One engineer writing rules for a 20-person team: equivalent to a security reviewer on every PR. The rules: never get tired, never miss a PR, and apply to every line of AI-generated code.'

Security Engineer Quick Reference for AI Coding

Quick reference for security engineers using AI coding rules.

• Core benefit: AI rules scale security knowledge to every developer and every AI-generated line of code
• Input validation: zod schemas on API endpoints, DOMPurify on form inputs, MIME checks on uploads — all automatic
• Authentication: withAuth middleware and Role enum checks on every route — no unprotected endpoints possible
• XSS prevention: no dangerouslySetInnerHTML, DOMPurify sanitization, URL protocol validation — always applied
• Injection prevention: parameterized queries, execFile not exec, no template interpolation of user input
• Access control: tenantId on all queries, assertOwnership before mutations — multi-tenant isolation by default
• Security headers: CORS, CSP, HSTS, rate limiting configured through rules — secure defaults everywhere
• Workflow: write rules once, prevent vulnerability classes forever — shift from reactive to proactive security