Web Security (OWASP)
Pathrule3 Rules • 2 Memories • 1 Skill
A baseline against the risks at the top of the OWASP Top 10:2025. Broken Access Control is still the number one application security risk, and Security Misconfiguration and Injection sit right behind it. This pattern enforces server-side authorization on every request, treats all input as hostile, defends against XSS and CSRF, and ships a secure-by-default configuration with the right response headers. It is the app-security layer that sits above your authentication, not a replacement for it.
Suggested path map
Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.
/ workspace root
web-security-review
src/
Enforce access control on the server, deny by default
Treat all input as hostile; parameterize and escape
Secure-by-default configuration and headers
Threat-model the request: where to check what
app/
Defend against XSS and CSRF
Rules
3Enforce access control on the server, deny by default/srchighstrictAuthorize every request server-side against the authenticated identity and the specific resource; the UI hiding a button is not access control.
| 1 | Broken Access Control is the #1 risk on the OWASP Top 10:2025 because it is so easy to get wrong: the UI hides an action, but the endpoint behind it never checks who is calling. |
| 2 | |
| 3 | - Authorize on the server for every request, checking the authenticated identity against the specific resource and action. Client-side checks are UX, not security; an attacker calls your API directly. |
| 4 | - Deny by default: a route with no explicit authorization should reject, not allow. Make "forbidden unless permitted" the framework default, not a check each handler must remember to add. |
| 5 | - Enforce object-level authorization (does THIS user own THIS record), not just "is logged in". Most access-control bugs are reading or mutating someone else's id (IDOR), so never trust an id from the request as proof of ownership. |
| 6 | - Check authorization on the server even for actions the UI does not expose. Hidden is not protected. |
Treat all input as hostile; parameterize and escape/srchighstrictValidate input against a schema at the boundary, use parameterized queries (never string-built SQL/commands), and escape output for its context.
| 1 | Injection stays near the top of the OWASP list because untrusted input keeps reaching an interpreter, whether SQL, a shell, or a template. |
| 2 | |
| 3 | - Validate and normalize input at the boundary against an explicit schema (allow-list what is valid; reject the rest). Validate type, length, format, and range, not just presence. |
| 4 | - Use parameterized queries / prepared statements or a query builder for every database call. Never build SQL (or NoSQL filters, shell commands, LDAP queries) by concatenating user input. An ORM does not save you if you drop to a raw string with interpolation. |
| 5 | - Escape output for the context it lands in (HTML, attribute, URL, JS, SQL). The same string is dangerous in one context and harmless in another. |
| 6 | - Never pass user input to a shell, `eval`, dynamic `require`, or a file path without strict validation; treat path and command construction as injection surfaces too. |
Defend against XSS and CSRF/apphighstrictRender user content as text (never trusted HTML), and protect state-changing requests with SameSite cookies plus anti-CSRF tokens or origin checks.
| 1 | Cross-site scripting and cross-site request forgery are the two ways the browser itself becomes the attacker's tool against your authenticated user. |
| 2 | |
| 3 | - Render user-supplied content as text by default; let the framework escape it. Reach for a raw-HTML escape hatch (`dangerouslySetInnerHTML`, `v-html`, `innerHTML`) only with input sanitized by a vetted sanitizer, never with raw user input. |
| 4 | - Set a Content-Security-Policy that restricts script sources; it is the backstop that limits damage when an XSS slips through. |
| 5 | - Protect state-changing requests against CSRF: set session cookies `SameSite=Lax` or `Strict`, `HttpOnly`, and `Secure`, and add anti-CSRF tokens or strict origin/referer checks for unsafe methods. A token-in-header API (not cookie-auth) is less exposed but still validate the origin. |
| 6 | - Store session tokens in `HttpOnly` cookies so script cannot read them; do not stash auth tokens in `localStorage` where an XSS can exfiltrate them. |
Memories
2Secure-by-default configuration and headers/srcShip hardened defaults: security response headers, no verbose errors or stack traces to clients, least-privilege config, and nothing sensitive in logs.
| 1 | Security Misconfiguration jumped to #2 on the OWASP Top 10:2025. The fix is boring and high-leverage: a hardened default config the whole app inherits. |
| 2 | |
| 3 | - Send the core security headers: `Content-Security-Policy`, `Strict-Transport-Security` (HSTS), `X-Content-Type-Options: nosniff`, a sane `Referrer-Policy`, and `X-Frame-Options`/`frame-ancestors`. A helmet-style middleware sets these in one place. |
| 4 | - Do not leak internals to clients: return generic error messages, never stack traces, framework versions, or raw exception text in a response. Log the detail server-side, behind the API. |
| 5 | - Disable what you do not use: debug endpoints, directory listing, default accounts and sample routes, permissive CORS (`*` with credentials), and verbose modes in production. |
| 6 | - Keep secrets and PII out of logs and error payloads, and default new config to the least-privilege, most-restrictive setting rather than the most convenient one. |
| 7 | |
| 8 | See /src for the access-control and input-validation rules; see /app for the XSS/CSRF rule. For credentials, see the secrets-env-management and auth-sessions-jwt-oauth patterns; for dependency risk, supply-chain-security. |
Threat-model the request: where to check what/srcA request crosses trust boundaries (network, auth, authorization, data); know which check belongs at which boundary so none is skipped.
| 1 | Most web vulnerabilities are a missing check at a boundary the request crossed. Knowing the boundaries makes the checks systematic instead of ad hoc. |
| 2 | |
| 3 | - At the edge: TLS/HSTS, rate limiting and abuse protection, request size limits, and CORS scoping. This is where you reject obviously hostile or excessive traffic. |
| 4 | - At authentication: establish who the caller is (see the auth pattern for sessions/JWT/OAuth). Authentication answers "who", not "may they". |
| 5 | - At authorization: for every resource and action, check that THIS identity may do THIS thing to THIS object. This is the layer most often missing and the OWASP #1. |
| 6 | - At the data boundary: validate and normalize input before it reaches a query, an interpreter, or storage; escape on the way out. Trust nothing that came from the client, including ids, headers, and hidden fields. |
| 7 | - Assume any single layer can fail and add defense in depth, so one missing check is not a full compromise. |
| 8 | |
| 9 | See /src for the access-control and input rules and /src for the secure-config memory. |
Skills
1web-security-review/rootPre-merge OWASP-oriented security checklist for any endpoint or view that handles auth, input, or output.
| 1 | --- |
| 2 | name: web-security-review |
| 3 | description: OWASP-oriented security review checklist. Run before merging any endpoint, view, or config change that handles authentication, authorization, user input, or output. |
| 4 | --- |
| 5 | |
| 6 | # Web security review (OWASP Top 10:2025) |
| 7 | |
| 8 | ## Access control (A01) |
| 9 | - [ ] Every endpoint authorizes on the server against the authenticated identity; no UI-only checks. |
| 10 | - [ ] Object-level ownership is verified; an id from the request is never trusted as proof of access (no IDOR). |
| 11 | - [ ] Routes deny by default; a missing authorization check rejects rather than allows. |
| 12 | |
| 13 | ## Injection & input (A05) |
| 14 | - [ ] Input validated/normalized against a schema at the boundary (allow-list). |
| 15 | - [ ] All DB access is parameterized; no SQL/NoSQL/shell/LDAP built by string concatenation. |
| 16 | - [ ] No user input reaches a shell, eval, dynamic require, or unvalidated file path. |
| 17 | |
| 18 | ## XSS / CSRF |
| 19 | - [ ] User content rendered as text; raw-HTML sinks only with a vetted sanitizer. |
| 20 | - [ ] CSP restricts script sources; state-changing requests protected by SameSite cookies + tokens/origin checks. |
| 21 | - [ ] Session tokens in HttpOnly+Secure cookies; no auth tokens in localStorage. |
| 22 | |
| 23 | ## Configuration (A02) |
| 24 | - [ ] Security headers set (CSP, HSTS, nosniff, Referrer-Policy, frame-ancestors). |
| 25 | - [ ] No stack traces / versions / internal errors returned to clients; secrets and PII kept out of logs. |
| 26 | - [ ] Debug endpoints, default accounts, permissive CORS, and verbose modes disabled in production. |
Why this pattern
AI agents enforce access control in the UI, trust request input, build SQL by string concatenation, and ship apps with default configs and no security headers.
Built for Web teams hardening application security beyond authentication.
Keeps your assistant from:
- Checking permissions only in the client while the API authorizes nothing
- Building SQL or shell commands by string concatenation of user input
- Rendering unescaped user content or trusting it as HTML
- Shipping default configs, verbose errors, and no security headers
- License
- Apache-2.0
- Version
- 1.0.0
- Updated
- 2026-06-09