Secure webapp implementation

Working code and safe code are different targets. A feature can pass every manual test and still hand an attacker the database, because the failure is in where a check runs or who is trusted, not in whether the code executes. Nothing in this skill is exotic; the common failures are ordinary and repetitive.

Apply these rules while writing the code. Retrofitting them after launch means rewriting the data model.

The five rules that cover most of it

1. Data you never collect can never leak from you. Before adding a field or an upload, ask whether the product actually needs to hold it, or whether the work can happen on the user's machine. Extract audio client-side instead of uploading whole videos; read local fonts instead of storing them; render output in the browser instead of on your disk.
2. The client can only hide things. Only the server can forbid them. Every rule enforced in the UI — plan limits, file length caps, admin-only buttons — is running on the user's computer and is editable by them. They can also skip your UI entirely and call the endpoint directly. Duplicate every limit server-side.
3. Authentication is not authorization. Knowing who someone is says nothing about what they may touch. Most real breaches are a logged-in user reaching another user's row by changing an ID. Every query that returns or mutates user-owned data must be scoped to the caller's identity.
4. Never trust a value from the browser for anything involving money or privilege. Price, plan tier, remaining quota, role, and payment status are server-derived facts. Look them up by ID server-side; do not accept them as request parameters.
5. Assume a key will leak and an account will be taken over. Design so the answer to "what could they reach?" is small: least privilege, per-row database rules, separate dev/prod credentials, human confirmation on destructive or outbound actions.

Route to the relevant reference

Read only the file that matches what is being built — the other four don't apply here and just cost context for nothing.

When the user asks for a limit, ask where it runs

Requests like "free users get 5 transcriptions a day" or "cap uploads at 10 minutes" are ambiguous by default. Implement them server-side, and say so explicitly in the response. If a UI-side check is also added for user experience, state plainly that it is cosmetic and the server check is the real one. Silently writing the limit in the frontend is the single most common way this goes wrong.

Production error handling

Development builds print stack traces, SQL, and internal paths. Shipping that to strangers hands over a map of the system. In production, return a generic message to the client and log the detail server-side. Also remove or password-protect any debug/test routes created during development — they usually survive to production untouched.

What to tell the user when finishing a feature

Close every feature's summary with exactly this template, fields in this order:

Server-side checks: <what runs on the server and cannot be bypassed from the client>
Client-side checks: <what runs in the UI only — cosmetic, not a security boundary>
Blast radius: <what an attacker could reach if this feature's credentials leaked>
Unverified: <the one thing that still needs a manual test before this is trusted>

A fixed template makes the summary scannable and makes an empty or skipped field obvious — do not paraphrase the field names or drop a field because it seems obvious in context.

If the work touched auth, per-user data, or spending, recommend the preflight-audit skill before deploying.