Secure Coding

This skill keeps you from introducing vulnerabilities while you build. It is prevention, not audit — it runs at the moment you write an endpoint, a form handler, or a database write, and bakes in the safe default before the bug exists.

Analogy: it is the seatbelt you put on before driving, not the crash investigator who shows up afterward. Audit tools (Trail of Bits, Semgrep, CodeQL) inspect the wreck. This skill stops the crash.

Scope

This skill is for the solo dev or small team who has no security tooling installed and just wants to ship without leaving holes. If a dedicated audit plugin is present, this skill still runs first — preventing a vuln is always cheaper than finding it later.

Trigger

Activate whenever code touches: a request handler/endpoint, user input, a database write, authentication, file uploads, secrets/env vars, CORS, or any third-party webhook. Default-deny mindset: code with no explicit security decision is the bug.

Discovery (max 3 questions, only if unknown)

1. Is this endpoint/data public, authenticated, or admin-only?
2. Does it touch personal data (email, name, payment, location, anything identifying a person)?
3. What is the backend — serverless functions (Vercel), a Node server, or a BaaS (Supabase/InsForge)?

The OWASP Top 10, as prevention rules

Apply the matching rule the instant you write the code. Each maps an OWASP 2021 category to a concrete default.

API security defaults

• Validate at the boundary with zod, and use .strict() schemas that whitelist exactly the allowed fields. This kills mass assignment — never spread req.body into a DB write; explicitly drop role, isAdmin, id, ownerId.
• Rate-limit every public and auth endpoint (express-rate-limit, or the platform's edge limiter). Auth routes get a stricter limit.
• CORS: allowlist origins explicitly. With credentials, * is forbidden by spec and a real hole.
• Return correct status codes — 401 vs 403, 422 on validation, 429 + Retry-After on limit.

User data & GDPR basics (for developers)

• Collect the minimum PII. Drop optional fields. Less data = less liability (GDPR Art. 5 minimization).
• Encrypt in transit (TLS) and at rest. GDPR Art. 32 cites encryption as the recommended safeguard.
• Set retention + deletion. Provide a way to delete a user's data on request.
• Never log PII. Redact emails, tokens, bodies before they hit logs or Sentry.

Secrets hygiene

• .gitignore .env, .env*.local, *.pem, *.key. Commit a .env.example with names only.
• Secrets live in the platform's encrypted store (Vercel env vars marked Sensitive), never in the repo.
• On Vite, only VITE_-prefixed vars reach the browser — a secret behind that prefix is a public leak.
• Rotate by add-new → redeploy → revoke-old. Optionally run gitleaks as a pre-commit net.

Server decides, client asks

The rule behind most real holes: anything the client sends is a request, not a fact.

• Prices, totals, roles, owners, statuses — computed or checked on the server.
• File uploads — the server builds the path (scoped to the user), chooses the bucket, restricts the type, caps the size.
• Identity — from a token the server validates, never from a cookie or field the browser can edit.
• Never switch to the admin/service client to make a permission error go away. That removes the permission. Find out why the user's own credentials were refused.

Public endpoints (no login)

A form or endpoint anyone can call needs, at minimum: a captcha or equivalent, a honeypot field (named so autofill won't fill it), a rate cap that does not depend on the caller's IP, and sanitizing of every value that ends up in a message sent to someone else.

Field notes

references/field-notes.md holds the security failures behind these rules — plus a working Content-Security-Policy recipe (per-request nonce, strict-dynamic, Report-Only rollout) and where secrets actually leak from. The three that cost the most:

1. A storage path taken from the form, uploaded with the admin client.
2. An order line saved at a client-chosen price.
3. An API key published inside a Markdown notes file by git add -A.

For database permissions on a BaaS, run rls-audit. For third-party webhooks, see integrations. For LLM calls, see ai-features.

Output

For each piece of code, deliver: the secure implementation, a one-line note on which risk it defends against, and any validation schema (zod) inline. When you spot a violation in existing code the user shows you, flag it with the fix — but the job is to write it safe the first time.

Reference

OWASP Cheat Sheet Series (~29k⭐), OWASP Top 10:2021, GDPR.eu / gdpr-info Art. 32. Tools: zod, helmet, express-rate-limit, bcrypt/argon2, gitleaks.