Secure Web App Coding

Use this skill to turn OWASP Top 10:2025, ASVS 5.0, Cheat Sheet Series, and selected WSTG material into practical web-app security guidance.

Modes:

• Inline mode: default for code edits. Write secure code quietly, and flag only the highest-impact issue you see nearby.
• Audit mode: for "review", "audit", "harden", "is this secure?", "check vulnerabilities", or incident follow-up. Read assets/audit-checklist.md and produce prioritized findings.

Explicit invocation options:

• $secure-webapp audit: full prioritized code/design review; read assets/audit-checklist.md.
• $secure-webapp quick-check: top-risk pass only; focus auth, authorization, secrets, injection/XSS, uploads, SSRF, and token handling.
• $secure-webapp harden: make secure code/config changes directly where the user has authorized edits; verify with focused tests/checks.
• $secure-webapp remediate: iterative audit→fix loop; read assets/remediate-checklist.md, auto-apply code-fixable findings each round, log open items, and repeat up to 8 rounds.
• $secure-webapp design-review: pre-implementation threat-model pass; identify trust boundaries, abuse cases, authorization model, data sensitivity, and failure modes.
• $secure-webapp report: generate a professional security audit report document from the findings in the current session. Read assets/report-template.md and write the report to docs/security-audit-report-YYYY-MM-DD.md in the project under review. Each confirmed finding must include: description, evidence (actual code), detailed step-by-step attack scenario, remediation applied, and verification. False positives and open items are documented separately. Requires a prior audit in the session; if none has been run, prompt the user to run $secure-webapp audit first.
• $secure-webapp update: self-update your local installation. Detect which client directory this skill is installed under (the path this SKILL.md was loaded from — .claude, .codex, or .gemini) and run npx --yes github:hov172/secure-webapp-skill --global in the terminal. The installer auto-detects every client already present, compares versions, and only reinstalls when a newer version is published (reporting "already up to date" otherwise). Pass --codex/--gemini/--claude to target one client, --check to report without changing files, or --force to reinstall regardless of version. For unattended updates, scripts/setup-auto-update.js registers a background scheduler (launchd, Task Scheduler, or cron) on macOS, Windows, or Linux.
• $secure-webapp maintain: update this skill package; use scripts/refresh.py, scripts/check_skill.py, and scripts/package_skill.py.

Load only the relevant reference files. Do not bulk-load all references.

Routing

For multi-category work, load the few references that directly apply.

Always-On Watchlist

Flag these in passing when seen in web code, with one concrete fix:

1. Missing server-side auth/ownership checks on resource routes. Prefer query-level scoping such as WHERE owner_id = :current_user.
2. Hardcoded secrets, credentials, JWT secrets, API keys, or committed .env files.
3. String-built SQL/NoSQL/shell queries. Use parameterized queries, safe builders, or argv APIs.
4. Plaintext or fast-hashed passwords. Use argon2id, scrypt, bcrypt, or PBKDF2 only when required.
5. JWT verification that accepts unpinned algorithms, lacks expiration/issuer/audience checks, or keeps secrets in code.
6. dangerouslySetInnerHTML, v-html, or innerHTML with user content. Render as text or sanitize with DOMPurify.
7. Credentialed CORS with wildcard/echoed origins. Use a strict origin allowlist.
8. Missing rate limits on login, signup, reset, MFA/OTP, or expensive endpoints.
9. Verbose production errors, stack traces, SQL/ORM details, or debug mode exposed to clients.
10. Open redirects from unvalidated next, returnTo, or URL parameters.
11. SSRF from fetching user-supplied URLs without allowlists and private-IP blocking after DNS resolution and redirects.
12. Logs containing passwords, tokens, session IDs, secrets, or unnecessary PII.
13. Client-only security controls: hidden fields, disabled buttons, client role claims, or frontend-only validation.
14. File uploads without size, type, path, storage, or generated-name controls.
15. Fail-open exception paths around auth, authorization, rate limits, feature flags, or transactions.
16. Non-atomic balance, quota, payment, inventory, coupon, or one-time-token state changes.
17. Floating CI actions/dependencies where pinning/lockfiles are expected. In monorepos and full-stack projects, dependency audits must run in every workspace (frontend/, backend/, etc.) — a clean audit in one package does not cover others. Flag if the CI audit threshold (--audit-level) is weaker than high.

Behavior

• Write secure code by default without long explanations.
• Name security-relevant choices briefly when useful.
• Match rigor to app stakes; do not force enterprise controls into throwaway prototypes.
• Do not generate intentionally insecure code. Offer the safe equivalent and explain the constraint in one sentence.
• For new trust-boundary features, quickly check: untrusted input, authorization, failure mode, stored data, and abuse path.
• For audit mode, inspect real code, ask only essential scoping questions, report severity + location + evidence + fix, and keep findings prioritized.
• For quick-check, do not produce a full checklist report; list only the highest-risk findings and next fixes.
• For harden, prefer small patches that preserve existing architecture; note any risk that needs manual/product approval.
• For remediate, read assets/remediate-checklist.md in full before starting. Run up to 8 audit→fix rounds. Auto-apply all code-fixable fixes; never prompt for confirmation except for product-decision-level changes (feature removal, breaking API change, file deletion). Log open items once; do not duplicate across rounds. Exit clean when code-fixable findings = 0 or round 8 completes.
• For design-review, produce assumptions, threat boundaries, must-have controls, and unresolved questions before implementation.
• For report mode, read assets/report-template.md in full before writing anything. Follow every step. The Attack Scenario section is mandatory and must be detailed enough for a non-technical stakeholder to understand the real-world consequence and for a developer to understand the exact exploit chain. Do not omit it, abbreviate it, or replace it with a one-liner. Write the report to a file — do not dump it into the chat.
• For maintain, validate and rebuild the .skill archive after edits.
• Do not cite OWASP requirement numbers in user-facing output unless asked.
• Do not claim to perform penetration testing; this skill is for code/design review and secure implementation.

Scope

This skill covers mainstream web apps across stacks such as Next.js, Express, Django, Flask, FastAPI, Rails, Spring, Laravel, Go, and similar frameworks. For niche areas not covered by references, say so and recommend the relevant OWASP primary source rather than guessing.

This skill is agent-agnostic. It works in Claude Code, Codex, Gemini CLI, and any other agent that loads skills or reads AGENTS.md/GEMINI.md. Where this file names a specific tool, use your environment's equivalent (file read, file edit/write, shell, and search); the security guidance itself is platform-independent.

Maintenance sources are in scripts/manifest.json; use scripts/refresh.py, scripts/check_skill.py, and scripts/package_skill.py when updating or publishing the skill.