agentleFS
michaelalbermichaelalber/ai-toolkit/skills/react-security-review/SKILL.md

react-security-review

Skill3 starsChanged 3 months agoMITView on GitHub

OWASP-based security review of React/TypeScript front-ends. Detects framework (Vite/CRA/Next), entry points, and data flows; scans the OWASP Top 10 (2025) mapped to React client-side risks (raw-HTML XSS, URL/protocol injection, bundled secrets, insecure token storage, dependency CVEs, missing CSP, open redirects); emits an exec summary plus graded findings. Use to audit React for vulnerabilities. Not for architecture grading (react-architecture-checklist).

  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Evidence or it is not a finding: Run the tools; cite file:line and the OWASP category.

    line 113
  2. Very specific:

    Federal/gov context → escalate: If NIST/FIPS/CUI/DOE applies, run security-review-federal after this base review.

    line 118

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

React Security Review

"Security is not a product, but a process." — Bruce Schneier

Core Philosophy

Shared across the dotnet / python / php / rust / react security reviews — same values, language-specific threats.

Grounding note: the knowledge base has no React corpus. Use collection="internal" for OWASP, collection="javascript" for JS/TS specifics, and collection="ui_ux" for safe-by-default UI; cite react.dev and the OWASP cheat sheets as the React authority. Never invent a react collection.

#ValueWhat it means
1Validate at boundariesEvery external input (URL params, postMessage, API responses) validated/typed before use; never trust client-controlled data — even your own API's response shapes.
2No raw HTML from untrusted dataOutput is escaped by default (JSX does this); the raw-HTML escape hatch is sanitized or never fed user data.
3Secrets out of the bundleNo API keys/tokens in client code; only intentionally-public VITE_/NEXT_PUBLIC_ values shipped; everything else stays server-side.
4Authn/authz is server-enforcedThe client never decides authorization — it only reflects it. Route guards are UX, not security; the API enforces.
5Least privilege & safe defaultsMinimal scopes; safe link/target defaults; fail closed on missing data.
6Protect data in transit & at restTLS only; tokens in memory or httpOnly cookies, not localStorage; no PII/tokens in logs or analytics.
7Dependencies pinned & auditedLockfile committed; npm audit / Snyk in CI; transitive CVEs reviewed (the npm tree is deep).
8Evidence-based, graded findingsEvery finding cites file:line + OWASP category + severity; report is graded and manager-readable.

Workflow

Shared skeleton: DETECT → SCAN → EXECUTIVE SUMMARY → GRADED FINDINGS.

DETECT     Framework (Vite/CRA/Next + React version), entry points (routes, forms, `postMessage`/
           `iframe`, external script tags), and the APIs / storage the app talks to.

SCAN       Walk the React Threat Checklist below, one OWASP category at a time. Gather evidence:
             npm audit --omit=dev                       # known CVEs in the dependency tree
             npx eslint . --plugin security             # eslint-plugin-security + jsx-a11y
             grep -rn "dangerously" src/                 # raw-HTML escape hatch usage
             grep -rn "localStorage\|sessionStorage" src/ # token storage
             grep -rn "VITE_\|NEXT_PUBLIC_\|process.env" src/ # secrets exposed to the bundle
           Every issue becomes a finding with file:line, OWASP category, and severity.

EXEC SUMMARY  Manager-friendly: risk grade, count by severity, top 3 risks in plain language.

FINDINGS      Technical table: severity · location · OWASP · finding · remediation.

React Threat Checklist (language-specific)

OWASP (2025)React / front-end checkSeverity signal
A01 Broken Access ControlAuthorization enforced by the API, not just hidden routes/buttons; no sensitive data fetched then client-side filtered; no IDOR via predictable IDs in client callsCritical
A02 Cryptographic FailuresTokens not in localStorage (XSS-readable) — prefer httpOnly cookies or memory; no home-rolled crypto in the client; HTTPS-only linksHigh
A03 Injection (XSS)JSX auto-escaping intact; the raw-HTML escape hatch (dangerously…InnerHTML) only on sanitized HTML (DOMPurify); no href={userUrl}/src= allowing javascript:; no dynamic code evaluation (eval, the Function constructor, injected <script>) on inputCritical
A04 Insecure Designtarget="_blank" paired with rel="noopener noreferrer"; postMessage handlers check event.origin; no trust of window.name/referrerHigh
A05 MisconfigurationContent-Security-Policy present; source maps not shipped to prod (or access-controlled); no * CORS reliance; React dev build not served in prodHigh
A06 Vulnerable Componentsnpm audit clean; lockfile committed; no abandoned/unmaintained UI deps; no latest rangesHigh
A07 Auth/Session FailuresLogin flows rate-limited server-side; tokens cleared on logout; no long-lived tokens in storage; refresh handled securelyHigh
A08 Integrity FailuresThird-party <script>/CDN tags use SRI (integrity); no untrusted dynamic import of attacker-controlled URLsHigh
A09 Logging FailuresNo tokens/PII sent to client analytics/error trackers (scrub before Sentry/GA); no secrets in console.logMedium
A10 SSRF / Open RedirectRedirect targets from query params allow-listed (no location.href = params.get('next')); image/iframe src from user input validatedHigh

Full per-category checklist + grounding query map: owasp react checklist.

State Block

<security-review-state>
language: react
mode: DETECT | SCAN | EXEC-SUMMARY | FINDINGS | COMPLETE
detected: [framework+version | entry points | apis/storage]
owasp_covered: [A01..A10 progress]
findings: [critical:N high:N medium:N low:N]
last_action: [what was just done]
next_action: [what should happen next]
</security-review-state>

Output Template

Shared across all security reviews. Executive summary template: executive summary.

## Security Review: [project] (React)
**Framework**: [Vite/CRA/Next + React x] | **Scope**: [paths] | **Risk grade**: [A–F]

### Executive Summary (manager-friendly)
[2–3 sentences: overall posture, the most serious risk in plain language, recommended next step.]
Findings: Critical [N] · High [N] · Medium [N] · Low [N]

### Technical Findings
| Severity | Location | OWASP | Finding | Remediation |
|----------|----------|-------|---------|-------------|
| CRITICAL | file:line | A03 | [pattern] | [fix] |

**Top 3 priorities**: 1. … 2. … 3. …

Risk grade: A no critical/high · B no critical, ≤2 high · C no critical, multiple high · D 1+ critical · F systemic (unsanitized raw HTML + secrets in bundle + client-only authz).

AI Discipline Rules

  • Evidence or it is not a finding. Run the tools; cite file:line and the OWASP category. No speculative findings.
  • Detect the framework first. React escapes JSX by default and Next.js adds headers/CSP options — confirm the safe defaults are used, not bypassed, before flagging.
  • Client guards are UX, not security. A hidden admin route is never a control; the finding is the missing server-side check, not the visible button.
  • Severity reflects exploitability + impact, not how unusual the pattern looks. XSS that reads a localStorage token is Critical; a missing rel="noopener" is Low/Medium.
  • Architecture, not here. Structural/maintainability issues belong to react-architecture-checklist — note and route.
  • Federal/gov context → escalate. If NIST/FIPS/CUI/DOE applies, run security-review-federal after this base review.

Integration with Other Skills

  • security-review-federal — Federal/gov overlay (NIST 800-53, FIPS, CUI, POA&M) applied on top of this base review.
  • react-architecture-checklist — Companion for structure/maintainability; run first for context.
  • supply-chain-audit — Deeper dependency/CVE and license analysis beyond npm audit (the npm tree is the largest attack surface here).
  • dotnet / python / php / rust-security-review — Sibling skills sharing this exact Core Values + workflow + output.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.