--- name: web-security-checks description: 18 rules from the Noesa course "Web Security, day by day". For a web developer who ships apps and wants to recognize the OWASP Top Ten, understand each attack, and apply concrete defensive fixes — no security background needed. --- # Web Security, day by day — the rules Use with: Claude Code or Claude (save as a skill), Cursor (save under .cursor/rules as .mdc), ChatGPT or any other assistant (paste the text below into custom instructions or a project's instructions). 18 rules, taken from the course at https://noesa.leafsoft.online/c/web-security Each heading is one thing the course teaches. Most are checks to run on your own output before presenting it as done; a few are background you are expected to have. 11 also name a mistake models make by default, under "Watch for". Apply these to the thing you are producing — the type, the schema, the query, the copy — not only to how you explain it. Where a rule names a field, a format or an identifier, that name belongs in the output. ## Set up your security bench Open an interactive lab, name the four parts of a safe security review, and keep all testing on systems you own. ## Map threats to trust boundaries Read the OWASP Top Ten as a map of broken trust boundaries in Petals. ## Bind data into SQL Reproduce SQL injection in the lab below and fix it with a parameterized query. **Watch for:** If you asked an AI to build Petals' search from a vague request, what safety step might its shortest working answer miss? It may join the search text into the SQL because that satisfies the visible feature. You must verify that values are bound separately and that dynamic identifiers come from an allowlist. ## Separate input from interpreters Recognize injection as a family and apply parameters, structured APIs, or allowlists to non-SQL interpreters. ## Render text, not script Distinguish reflected and stored XSS in Petals and fix the server-rendered path with safe rendering. ## Use safe DOM sinks Reproduce DOM XSS in local Petals and fix it with safe sinks and context-aware output handling. **Watch for:** If you asked an AI to add Petals' preview panel, which browser-side shortcut should you inspect before trusting the result? It may choose `innerHTML` because it renders the requested content with one assignment while missing where that content came from. Trace source to sink and require a text sink or a narrowly sanitized rich-text path. ## Constrain scripts with CSP Read a Content Security Policy header, add a starter policy, and watch the browser enforce it against a live payload. **Watch for:** If you asked an AI for a CSP header, why could a polished-looking policy still be wrong for your app? It does not know every script source, inline dependency, or route behavior in your deployment unless you supply that context. Start with report-only evidence, remove unsafe dependencies, and verify the enforced header on each relevant response. ## Respect the same origin Explain scheme, host, and port as an origin and predict which cross-origin actions the browser blocks or allows. ## Harden session cookies Read Set-Cookie attributes and configure HttpOnly, Secure, SameSite, Path, and host scoping for Petals. ## Require intent for state changes Reproduce CSRF on local Petals and fix it with SameSite plus a server-validated CSRF token. **Watch for:** If you asked an AI to stop CSRF, what incomplete one-line fix might it offer? It may set `SameSite` and stop because that is the common browser-level control. You must check the actual authentication flow and require a server-validated token for sensitive state changes rather than treating one cookie flag as proof of intent. ## Return JSON as data Explain XSSI and harden Petals JSON endpoints against script inclusion and JSON hijacking patterns. ## Manage authentication sessions Identify common authentication and session failures and harden Petals login, logout, and password storage behavior. **Watch for:** If you asked an AI to build login and logout, which security work could disappear outside the happy path? It may produce credential checking and a cleared cookie while missing session rotation, server-side revocation, reset-token expiry, rate limits, and secret-safe logging. Review identity as a lifecycle, not as two endpoints. ## Authorize every object Reproduce an IDOR in local Petals and fix it with server-side, per-object authorization. **Watch for:** If you asked an AI to generate a note route by ID, what authorization gap should you expect to inspect? It may add a login check and then load the object by ID because that is the shortest common CRUD pattern. Verify that every read and write scopes the object to the acting user, tenant, role, or membership at the server data boundary. ## Allow only safe server fetches Explain SSRF and harden a Petals URL fetcher with allowlists, parser discipline, and network blocks. **Watch for:** If you asked an AI to validate a server-side URL fetcher, where might a hostname check stop too early? It may approve the original scheme and host but miss redirects, DNS resolution, alternate address forms, network reach, and response limits. Verify the final destination and enforce egress controls outside the application check as well. ## Deserialize only trusted data Explain insecure deserialization and replace native object restore with signed, schema-validated data. **Watch for:** If you asked an AI to secure a saved-cart document, what might it wrongly treat a valid signature as proving? It may stop at signing because integrity solves the visible tampering problem. A signature does not prove authorization, freshness, secrecy, schema validity, or business validity; you still check each of those before domain behavior runs. ## Break code-execution chains Explain RCE as a chain outcome and list the layers that stop Petals from turning input into server code execution. **Watch for:** If you asked an AI to patch one code-execution sink, what part of the risk could remain outside that code change? It may fix the visible dangerous call while missing another chain link or the runtime's blast radius. Draw the path from input through execution to privileges, secrets, filesystem, and network, then remove or contain more than one link. ## Use cryptography through libraries Identify cryptographic failures in Petals and choose library-backed password hashing, TLS, random tokens, and secret handling. **Watch for:** If you asked an AI which cryptographic primitive to use, what decision would still depend on your system? It may name a vetted library yet lack your threat, deployment budget, key ownership, rotation path, and compatibility constraints. You must match the primitive and parameters to the property, then verify randomness, storage, rotation, and failure behavior. ## Harden Petals for release Run a defensive hardening review over Petals and produce an OWASP-style secure-coding checklist for your own app. **Watch for:** If you asked an AI for a release-security checklist, why would the result still need a human threat model? It may produce a fluent generic list without knowing Petals' real boundaries, data, deployment, or acceptable risk. Map each item to a concrete control, proof, owner, and blocker, and never let a critical invariant disappear inside an average score.