antivibe-rails-starter / rules

---
description: Security architecture rails (AntiVibe) — non-negotiable constraints for all code generation
apply_when: always
priority: 100
---

# Security Architecture Rails (AntiVibe)

You MUST follow these security constraints on every code generation task. These are non-negotiable architectural decisions — not suggestions.

## Data Rules
- Secrets (API keys, tokens, credentials) MUST use server-side environment variables. NEVER place secrets in client-side code, config files committed to git, or frontend bundles.
- Confidential data (email, PII, private messages) MUST be encrypted at rest and in transit.
- All database tables MUST have Row Level Security (RLS) policies. No table is exempt.
- Data classification: Public (posts, profiles) | Internal (preferences) | Confidential (email, DMs) | Secret (API keys, tokens). Handle each tier accordingly.

## Auth Rules
- All API endpoints MUST require authentication unless explicitly documented as public.
- Authorization checks MUST happen server-side. Never trust client-side role checks.
- Rate limit all authentication, registration, and password reset endpoints.
- Use parameterized sessions or JWT with proper expiry. Never roll custom auth crypto.
- Implement CSRF protection on all state-changing operations.

## Input Rules
- Validate ALL user input server-side. Client-side validation is UX, not security.
- Use parameterized queries or ORM methods. NEVER concatenate user input into SQL strings.
- Sanitize all output to prevent XSS. Use framework-provided escaping.
- Validate file uploads: check MIME type, enforce size limits, scan for malicious content.
- Reject unexpected fields (allowlist approach, not blocklist).

## Dependency Rules
- Only use well-known, actively maintained packages with >1000 weekly downloads.
- ALWAYS verify a package exists on the registry before recommending or installing it.
- Pin exact versions in lock files (package-lock.json, poetry.lock, etc.).
- Never add packages with install scripts you haven't reviewed.
- Prefer stdlib or framework-provided solutions over third-party packages for security-critical operations (crypto, auth, sanitization).

## Infrastructure Rules
- HTTPS on all endpoints. No exceptions.
- Set security headers on every response: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
- Debug mode, verbose error messages, and stack traces MUST be OFF in production.
- CORS policies must be explicit — never use wildcard (*) origins with credentials.
- Log security-relevant events (auth failures, permission denials, input validation failures) but NEVER log secrets or PII.

## Code Generation Behavior
When generating code that touches any of the above areas:
1. Apply the relevant constraint automatically — do not wait to be asked.
2. If a user request conflicts with these rails, explain the security risk and offer the secure alternative.
3. Include the security mechanism in your first generation — don't leave it as a "TODO" or "you should add this later."
4. When creating database schemas, ALWAYS include RLS policies in the same response.
5. When creating API endpoints, ALWAYS include auth middleware in the same response.

## Network & Domain Rules
- ONLY suggest API integrations with domains listed in `.antivibe/config.yaml` allowed_domains.
- If `.antivibe/config.yaml` exists, check it before recommending any external service.
- NEVER suggest connecting to domains on the blocked list.
- When adding fetch/axios/http calls, verify the target domain is whitelisted.

## Package Installation Rules
- Before suggesting `npm install` / `pip install` / `gem install`, run `bin/validate-package.sh <package>`.
- If the package fails validation, DO NOT install it — suggest an alternative.
- Check `.antivibe/config.yaml` blocked_packages before recommending ANY dependency.
- After installing any package, run the appropriate audit command.

## Pre-Commit Security
- NEVER commit code with known vulnerabilities.
- Run `bin/pre-commit-scan.sh` before every commit.
- If scan finds HIGH+ severity issues, fix them before committing.
- Treat pre-commit scan failures as blocking — not advisory.