A Web App Security Checklist for Launch

Security is a launch gate, not a later sprint

A web app security checklist is most useful at exactly the moment teams are least inclined to slow down: the week before launch. The pressure to ship makes it tempting to defer security to a hardening sprint that, in practice, never quite arrives. But the cheapest time to close a vulnerability is before any attacker has had a chance to find it, and most pre-launch security work is a day or two of focused effort, not a project. Here is the gate we run web applications through before they take real traffic.

Authentication and session handling

Most breaches start at the front door. The auth checks are unglamorous and non-negotiable:

• Hash passwords with a slow, salted algorithm built for the purpose — never a general-purpose fast hash, and never anything reversible.
• Set session cookies HttpOnly, Secure, and with a sensible SameSite value so a script cannot read them and a cross-site request cannot ride them.
• Enforce authorisation on the server for every protected action. A hidden button is not access control; the check has to live where the request is handled, not in the UI.
• Rate-limit login and password-reset endpoints so credential-stuffing is slow and noisy instead of free.

The recurring mistake is checking that a user is logged in but not that they are allowed to touch this particular record. Verify ownership, not just identity.

Treat every input as hostile

Injection and cross-site scripting remain at the top of the list because the underlying mistake — trusting data from the client — is so easy to make. Two rules cover most of it: use parameterised queries everywhere so user input can never be interpreted as part of a database command, and escape output by context so a value rendered into a page cannot become executable script. Validate at the boundary with a schema, reject what does not fit, and never reflect raw user input back into a response.

Every value that crossed the network from a client is hostile until your code has proven otherwise. The proof has to happen on the server.

Send the security headers

A handful of HTTP response headers shut down whole classes of attack for the cost of a few lines of configuration, and shipping without them is leaving easy wins on the table:

• A Content-Security-Policy to constrain what scripts can run — the strongest single defence against cross-site scripting.
• Strict-Transport-Security so browsers refuse to talk to your site over plain HTTP.
• X-Content-Type-Options set to nosniff, and a sensible frame-ancestors policy to prevent clickjacking.

Build the policy against your real asset origins rather than copying a block from elsewhere; a cargo-culted CSP either breaks the site or is loose enough to be theatre.

Secrets and dependencies

Two quieter risks close out the gate. First, secrets: no API key, password, or token in the source tree or the client bundle, ever. Load them from environment or a secret manager, fail loudly at startup if a required one is missing, and rotate anything that has ever been committed. Second, dependencies: a modern app is mostly other people's code, and that code has known vulnerabilities. Run an automated audit of your dependency tree, patch the high-severity findings before launch, and make that scan part of the pipeline so the check repeats on every change rather than rotting after day one.

Decide what your errors and logs reveal

Two final leaks are easy to miss because they are about what the application says, not what it does. The first is error messages. A stack trace or a raw database error returned to the browser is a free reconnaissance gift — it tells an attacker your framework, your schema, sometimes a file path on your server. Return a generic message to the client and keep the detail in your server-side logs where only you can read it. The second is the logs themselves: it is alarmingly common to write a password, token, or full card number into a log line while debugging and forget to take it out, turning your log store into a secondary breach surface.

• Catch unhandled errors at the edge and return a clean, generic response; never let an internal exception reach the user verbatim.
• Scrub credentials, tokens, and personal data out of log lines — a redaction layer beats relying on every developer to remember.
• Set security-relevant defaults to safe: disable verbose error output and stack traces in production builds, not just in your intentions.

Assume an attacker reads every error message and every log line you produce. Decide on purpose what those are allowed to say.

How BSH can help

BSH Technologies hardens web applications before they ship and after — auth and session review, input-handling and injection testing, header and transport configuration, secret hygiene, and dependency auditing wired into delivery. Security is a core practice for us, alongside zero-trust and managed protection for clients well beyond Kerala. If a launch is coming and security is still on the someday list, let us run the gate with you so it is not the part you regret.