PRACTICAL GUIDE · JAVASCRIPT & TYPESCRIPT
Before you deploy:
seven code security checks.
A working app can still expose data. Use these checks to ask better questions about the code you own, including code written with an AI assistant. Record evidence and unresolved questions before release.
01 / Prove authorization on the server.
For each sensitive read or write, identify the server-side ownership and role check. A hidden button is not an access-control rule. In your own test environment, use two separate users to verify that one cannot read or change the other's private record.
Keep: the endpoint, expected permission, test fixture and actual result. A single-file static review cannot establish complete cross-user authorization.
02 / Keep credentials out of source and logs.
Check committed files, configuration, build output and logging paths for credentials. A public frontend cannot keep an embedded credential secret. If a real credential was exposed, revoke or rotate it at its issuer; deleting the visible string alone is insufficient.
Keep: a redacted finding and rotation status. Never paste live credentials into a demo or a public discussion.
03 / Trace dynamic code execution.
Review uses of eval, new Function and shell execution. Follow the input from its origin to the call. Prefer explicit operations and allowlisted arguments over building executable strings from input.
Keep: the input source, call location and constraints. A matched call is a candidate for review, not proof that an attacker can exploit it.
04 / Preserve TLS certificate validation.
Investigate rejectUnauthorized: false and process-wide switches that disable certificate validation. Fix certificate trust configuration rather than carrying a development bypass into production.
Keep: the affected client, environment and certificate configuration. Review reachability and runtime behavior before assigning impact.
05 / Validate at boundaries and encode at sinks.
Define accepted types, lengths and values on the server. Use parameterized database queries, output encoding appropriate to the rendering context, and explicit upload restrictions. Input validation does not replace authorization.
Keep: representative valid and invalid cases. Check the actual query and rendering paths, not just a form's browser validation.
06 / Review what you ship.
Inspect lockfile changes, dependency advisories and runtime permissions. A clean advisory report does not establish that the application's own logic is safe. Give integrations only the permissions they need.
Keep: the package versions, advisory status, deployment configuration and unresolved risks.
07 / Verify the fix and keep the limits visible.
For each proposed fix, reproduce the original failing case in an authorized environment, apply the change and rerun it. Also check that legitimate behavior still works. Record what was not tested and what needs a broader review.
Keep: a revision or content hash, before-and-after evidence and the person responsible for the release decision.
Published October 15, 2026. Review only code and systems you are authorized to assess. Privacy · Terms · Paid review options