Security Best Practices

Security Best Practices

Use this skill when the job is to name one missing security layer and turn it into a bounded hardening brief.

The job is not to dump a giant OWASP list, middleware catalog, or scanner parade. The job is to: 1. frame the surface and risk, 2. choose one primary hardening mode, 3. recommend the smallest credible first slice, 4. name the verification ladder, 5. route adjacent work honestly.

Read these support docs first:

• references/modes-and-boundaries.md
• references/mode-packets-and-route-outs.md
• references/hardening-review-checklist.md
• references/verification-ladder.md

When to use this skill

• A team says “make this secure” and the missing security layer is still unclear
• A web app, API, marketing-site flow, admin panel, or game-service surface needs a hardening pass before launch or migration
• You need to decide whether the main problem is CSP/headers, cookies/CSRF, abuse controls, validation/unsafe execution, secret handling, or weak verification
• Scanner findings, OWASP requests, or launch-review notes need to be converted into one prioritized hardening brief
• The current stack has some controls already, but trust is low and the next verification step is unclear

When not to use this skill

• The main job is choosing an auth vendor, session architecture, org/member model, or enterprise SSO path → authentication-setup
• The main job is API contract/interface design before security controls are slotted in → api-design
• The main job is schema constraints, token tables, indexes, or migration safety → database-schema-design
• The main job is backend regression coverage or auth/security test implementation → backend-testing
• The main job is fixing a specific vulnerability in code or reviewing a concrete diff → debugging or code-review
• The main job is secret injection mechanics, toolchain bootstrapping, or environment wiring → system-environment-setup / environment-setup
• The main job is cloud IAM, VPC/network, or broader infrastructure security → use the infrastructure-specific skill instead of this app-hardening anchor

Instructions

Step 1: Frame the hardening job before naming tools

Capture the minimum facts first.

security_intake:
  surface: frontend | backend-api | fullstack | edge-worker | marketing-site | game-service-web | mixed | unknown
  workflow_type: new-build | hardening-pass | audit-review | launch-readiness | incident-follow-up | migration
  auth_session_model: cookie-session | bearer-token | mixed | unknown
  current_controls:
    - headers-csp
    - csrf
    - rate-limit
    - validation
    - secret-store
    - scanning
    - none
  primary_risk: xss-browser-policy | csrf-session | abuse-automation | injection-unsafe-execution | secret-exposure | verification-gap | mixed | unknown
  environments: local | preview | staging | prod | multi-env | unknown
  ownership: app-team | platform | security | shared | unknown

Rule: do not start with “install Helmet,” “turn on CORS,” or “just add WAF rules.” First label the missing layer.

Step 2: Choose exactly one primary hardening mode

Use the router in references/mode-packets-and-route-outs.md.

Primary modes: 1. browser-perimeter-policy 2. session-cookie-csrf 3. abuse-controls 4. validation-unsafe-execution 5. secrets-runtime-config 6. review-verification

Pick the highest-risk missing layer as primary. List everything else as follow-up, not as equal co-owners.

Step 3: Keep the invariants visible

These rules survive every answer:

• CORS, auth, CSRF, rate limiting, validation, and secrets are separate concerns even when they touch the same route
• browser-policy work may need staged rollout or report-only verification
• framework defaults help, but they do not prove full coverage
• secret scanning is detection, not storage/rotation policy
• WAF and rate limiting are compensating/perimeter controls, not full substitutes for app-layer fixes
• every recommendation needs a matching verification step

Step 4: Build the security hardening brief

Return this structure:

# Security Hardening Brief

## Scope
- Surface: ...
- Workflow type: ...
- Primary mode: ...
- Confidence: high | medium | low

## Current control state
- Controls already present: ...
- Missing or untrusted controls: ...

## Highest-risk gaps
1. ...
2. ...
3. ...

## Recommended first slice
1. ...
2. ...
3. ...

## Verification plan
- Manual review: ...
- Static/policy checks: ...
- Dynamic/runtime verification: ...
- Operational evidence: ...

## Ownership and route-outs
- Primary owner: ...
- Adjacent skills / teams: ...

Step 5: Use the mode packet, not a giant checklist

Pull the packet from references/mode-packets-and-route-outs.md.

Mode rules:

• browser-perimeter-policy → headers, CSP, framing, secure transport, report-only rollout, proxy/CDN vs app ownership
• session-cookie-csrf → cookie flags, state-changing browser routes, origin assumptions, web vs API/mobile differences
• abuse-controls → login/reset/form/expensive-endpoint protection, per-route vs global limits, bot carve-outs, monitoring
• validation-unsafe-execution → trust boundaries, validation/encoding, uploads, SSRF, command execution, dangerous patterns
• secrets-runtime-config → secret-vs-config separation, storage/injection, least privilege, rotation/revocation, client-bundle avoidance
• review-verification → classify findings, keep/fix/add/defer decisions, smallest proof ladder, honest ownership

Step 6: Route adjacent work explicitly

Use these route-outs when the problem crosses boundaries:

Output expectations

A strong answer from this skill should: 1. identify the primary missing layer, 2. recommend one bounded first slice, 3. name the verification ladder, 4. avoid pretending one library/tool solves everything, 5. route adjacent work outward instead of absorbing it.

Examples

Example 1: cookie-based admin app hardening

Input

Our Next.js admin app uses cookie sessions. POST routes lack CSRF protection and staging/prod cookie flags drift.

Output direction

• choose session-cookie-csrf
• identify which routes need CSRF protection and which cookie flags must be fixed
• include a verification step for staging/prod drift
• avoid reframing the task as auth-vendor selection

Example 2: marketing-site form abuse

Input

Our signup and demo-request forms are getting spammed even after adding a honeypot and CAPTCHA.

Output direction

• choose abuse-controls
• separate form abuse controls from generic CSP/header work
• recommend route-aware throttles / anti-automation steps plus monitoring
• keep broader infrastructure or vendor-rule authoring outside the core brief

Example 3: game-service secret leakage risk

Input

We have a game companion site plus backend APIs. I’m worried partner keys and admin tokens are drifting into CI logs and maybe client bundles.

Output direction

• choose secrets-runtime-config
• separate secret detection from storage/rotation/injection policy
• route environment bootstrapping details away when needed
• include revocation/rotation proof requirements

Example 4: scanner report with weak ownership

Input

The scanner says weak CSP and missing headers, but the app already added middleware and no one trusts the result.

Output direction

• choose review-verification or browser-perimeter-policy
• keep middleware installation distinct from rollout proof
• recommend staged/report-only verification or a scanner/runtime handoff

Best practices

1. Choose the missing security layer before naming tools. 2. Keep browser policy, session safety, abuse controls, validation, secrets, and verification separate. 3. Pair every recommendation with evidence that would prove it worked. 4. Treat framework defaults and scanners as inputs, not final answers. 5. Prefer one bounded hardening brief over a giant compliance dump.

References

• OWASP Application Security Verification Standard
• OWASP Cheat Sheet Series
• MDN: Content Security Policy
• MDN: Set-Cookie
• OWASP ZAP
• GitHub CodeQL code scanning

Hardening Review Checklist

Use this checklist to turn a vague security review into a concrete brief.

1. Scope and surface

• What surface is under review: frontend, backend/API, fullstack, edge, worker, or mixed?
• Is this a greenfield build, hardening pass, migration, audit, or incident follow-up?
• Which environments matter right now: preview, staging, prod?

2. Browser / perimeter controls

• Is HTTPS-only behavior enforced where it should be?
• Are security headers intentional, not just copied from a tutorial?
• Does CSP need staged rollout / report-only mode?
• Are embed/frame rules and clickjacking posture explicit?

3. Session / cookie / CSRF controls

• Does the app use session cookies, bearer tokens, or both?
• Are HttpOnly, Secure, and SameSite values consistent with the real deployment?
• Which state-changing browser routes require CSRF protection?
• Is anyone incorrectly relying on CORS to solve CSRF?

4. Abuse controls

• Which workflows are sensitive: login, reset, invite, upload, expensive API calls?
• Are limits global only, or route/account/device aware where needed?
• Are there lockout / backoff / challenge strategies beyond simple 429s?
• Which metrics confirm the controls work in production?

5. Validation / unsafe execution

• Where does untrusted input enter the system?
• Are validators and parameterized queries present at the real trust boundary?
• Is output encoding/sanitization/trusted-types guidance needed?
• Are file upload, SSRF, command execution, or deserialization surfaces relevant?

6. Secrets / runtime config

• Which values are actual secrets?
• Where are they stored and injected today?
• Is build-time or client exposure possible?
• What is the rotation / revocation plan?

7. Verification

• What can be checked by manual review?
• What belongs in static analysis or code scanning?
• What should be exercised dynamically (security test, DAST, smoke check, or runtime monitoring)?
• Which adjacent skills or owners must be involved before the issue is genuinely closed?

Security Mode Packets and Route-Outs

Use this note after the primary security layer has been classified.

1. browser-perimeter-policy

Use when the core risk is browser-enforced or transport-enforced defense.

Focus

• HTTPS-only expectations and redirect/HSTS posture
• CSP rollout strategy, report-only use, framing/embed policy
• clickjacking protections and browser trust boundaries
• proxy/CDN/framework ownership splits

Return

• mandatory browser/perimeter controls now
• staged rollout/testing items
• breakage risks for analytics, embeds, third-party scripts, previews, or uploads
• route-outs when implementation becomes framework-specific

Route-outs

• auth/session architecture → authentication-setup
• broader UI accessibility/perf side effects → neighboring frontend skills
• infra/CDN rule authoring beyond app posture → infra-specific skill

2. session-cookie-csrf

Use when state-changing browser flows, cookie flags, or origin assumptions are the main risk.

Focus

• HttpOnly / Secure / SameSite truthfulness
• which routes/actions need CSRF protection
• browser versus API/mobile/native client differences
• session lifetime / refresh boundaries

Return

• required cookie/session flags
• actions that need CSRF protection
• where token/API clients differ from browser assumptions
• auth-architecture handoff if the session model itself is still undecided

Route-outs

• hosted/native auth choice or org/member design → authentication-setup
• backend auth regression coverage → backend-testing

3. abuse-controls

Use when the real issue is brute force, bot traffic, spam submissions, or expensive endpoint misuse.

Focus

• login/reset/invite/form/upload/paid-endpoint abuse
• route/account/device-aware controls versus global limits
• challenge/backoff/queue/lockout decisions
• verified-bot or search-crawler carve-outs
• telemetry showing the controls actually work

Return

• most important abuse surfaces
• the safest control layer per surface
• where softer controls beat blunt denial
• monitoring/ownership expectations

Route-outs

• vendor-specific WAF rule authoring or bot platform setup → vendor/infra skill
• ongoing alerts/metrics platform work → monitoring-observability

4. validation-unsafe-execution

Use when untrusted input, unsafe output handling, uploads, SSRF, command execution, or deserialization risk is primary.

Focus

• trust boundaries and validation points
• parameterization / encoding / sanitization expectations
• high-risk entry points: upload, outbound requests, command execution, deserialization
• banned patterns and review requirements

Return

• highest-risk entry points
• required validation/encoding strategy per surface
• banned patterns or libraries
• tests/reviews needed before release

Route-outs

• code-level bug fixing or exploit patching → debugging
• concrete diff risk review → code-review

5. secrets-runtime-config

Use when secret handling, exposure, scoping, or lifecycle policy is the main problem.

Focus

• which values are true secrets versus normal config
• storage/injection boundaries
• build-time, CI/log, runtime, and client exposure risks
• least privilege, rotation, revocation, break-glass handling

Return

• secret inventory by sensitivity
• where secrets should live and how they should be injected
• rotation/revocation expectations
• what must never reach repos, logs, or client bundles

Route-outs

• environment bootstrap / local-dev injection mechanics → system-environment-setup / environment-setup
• deployment platform/env rollout specifics → deployment-automation or platform skill

6. review-verification

Use when controls exist but ownership is unclear, findings are vague, or proof is weaker than the claims.

Focus

• classify findings into the right security layer
• keep / fix / add / defer decisions
• smallest proof ladder: manual → static/policy → targeted test → dynamic/runtime → operational evidence
• ownership by issue class

Return

• reclassified findings
• smallest high-value remediation order
• verification ladder by issue class
• evidence still missing before the app can be called hardened

Route-outs

• backend test implementation → backend-testing
• code-level fixes → debugging
• review of a concrete change → code-review

Quick routing heuristic

• If the request says “secure our login flow,” ask whether the missing layer is session/CSRF, abuse controls, auth architecture, or test coverage.
• If the request says “OWASP hardening,” choose the missing layer before recommending any tool.
• If the request came from a scanner finding, use review-verification first unless the missing layer is already obvious.
• If the request is mostly infra/IAM/network policy, this skill is not the primary owner.

Security Hardening Modes and Boundaries

Use this note when the request blurs multiple security topics and the main skill needs a fast routing decision.

Primary modes

Adjacent skills

Routing heuristics

• If the request says “secure our login flow,” ask whether the missing piece is auth architecture, CSRF/cookies, abuse controls, or tests.
• If the request says “OWASP hardening,” pick the missing layer before choosing tooling.
• If the request came from a scanner finding, route to Review / verification first, then hand off concrete code/schema/auth work.
• If the request is mostly infra/IAM/network policy, this skill is not the primary owner.

Security Verification Ladder

A hardening recommendation is stronger when it names the evidence that would prove it worked.

Level 1 — Manual review

Use for:

• header/cookie config inspection
• routing whether a finding is auth, schema, API, or app-hardening work
• reviewing whether a CSP or same-site policy is internally consistent

Questions:

• What exact control changed?
• Which routes/components/environments does it cover?
• What assumptions remain unverified?

Level 2 — Static analysis / policy checks

Use for:

• unsafe pattern detection
• secret leakage checks
• dependency or code scanning
• CI policy validation

Examples:

• GitHub CodeQL or equivalent code scanning
• secret scanners / config linters
• framework-specific secure-default lint rules

Level 3 — Targeted tests

Use for:

• auth/session regressions
• CSRF-protected state changes
• header presence assertions
• abuse-control behavior on sensitive endpoints

Good practice:

• Add a focused regression test when the control is easy to re-break.
• Route broader backend coverage design to backend-testing.

Level 4 — Dynamic / runtime verification

Use for:

• DAST or automated scanners such as ZAP
• replaying sensitive flows in staging
• confirming alerting/metrics around abuse controls
• verifying browser-policy rollout after CSP/report-only changes

Level 5 — Operational evidence

Use for:

• proving rate limits actually absorb abuse without harming normal users
• proving secret rotation / revocation processes work
• proving suspicious activity is observable and owned

Rule of thumb

• New control, no evidence -> not done.
• Library installed, no scoped verification -> not done.
• Scanner finding routed to the wrong layer -> reclassify before fixing.