Frontend security
AppSec Skills — 15 plug-and-play Claude Code security skills that audit, harden, and fix any website or app before you ship it. OWASP Top 10, auth, API, database, frontend, backend, cloud, dependencies, secrets, and pentest-style checks — all defensive, all evidence-based.
npx -y skills add Rootx202/appsec-skills --skill frontend-securityAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 23 days oldThe repository was created 23 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Frontend/client-side security auditor covering React, Next.js, Vue, and general SPA/SSR concerns — server components, server actions, middleware, cookies, CSP headers, hydration, and client-side XSS. Use when reviewing a frontend application's client-side and edge-runtime security specifically, for any project.
SKILL.md
3.1 KB, as published. Nobody here has run it
Frontend Security — Client-Side & Rendering Layer Auditor
A specialized skill for auditing frontend security and the boundary between server and client rendering.
When to use this
- Any React/Next.js/Vue/SPA project
- Reviewing Server Actions / Server Components / Middleware (Next.js) or equivalents
- Suspected leakage of sensitive data to the client, or CSP/XSS concerns
Core Checks
Server vs. Client Boundary
- Make sure sensitive data (secrets, keys, other users' data) is never passed as props from a server-rendered component into a client component without necessity — anything that reaches a client component is visible in the browser bundle/network.
- Environment variables: only variables explicitly intended for the client (e.g. prefixed
NEXT_PUBLIC_,VITE_,REACT_APP_) should be exposed; check that a real secret wasn't mistakenly given that prefix.
Server Actions / Server-Side Handlers
- Every server action is effectively an API endpoint — it must contain its own authentication and authorization checks, not rely on being "hidden" in the UI.
- Validate inputs inside the handler itself always, even if client-side validation also exists (the client is never trusted).
Middleware
- Confirm route-protection middleware (e.g., session checks) actually covers every path it's meant to via the correct matcher/config — check for accidentally unprotected routes.
Cookies & Security Headers
- Session cookies:
HttpOnly,Secure,SameSite - Baseline security headers present:
Content-Security-Policy,X-Frame-Options/frame-ancestors,X-Content-Type-Options: nosniff,Referrer-Policy - CSP avoids
unsafe-inline/unsafe-evalunless strictly necessary
XSS in Component Frameworks
- Any use of
dangerouslySetInnerHTML/v-html/raw DOM injection — content must be sanitized (e.g., DOMPurify) before use - User-supplied URLs rendered as links (
href={userInput}) — rejectjavascript:scheme
CSRF
- Confirm any traditional state-changing endpoint (POST/PUT/DELETE) is protected by a CSRF token or an appropriate SameSite-cookie strategy, especially outside frameworks that provide built-in protection for their own action mechanism.
Hydration & SSR Data Leakage
- Confirm no per-user personalized data is rendered on a page that could be shared through caching (CDN/edge cache) across different users — a common cross-user data-leak vector in SSR apps.
Report Format
Component/Route: [path]
Issue: [problem]
Severity: Critical/High/Medium/Low
Evidence: [code]
Impact: [impact]
Fix: [suggested change]
Rules
- Never treat client-side validation alone as sufficient — always require a matching server-side check.
- For purely aesthetic/visual concerns (not security), defer to a design skill instead of conflating the two.