The Web Application Security Checklist: 25 Controls to Verify Before Launch

The email that prompts this article arrives in every founder’s inbox eventually. An enterprise prospect is interested, the deal is real, and attached is a security questionnaire: 40 questions, sometimes 200. You read “Is customer data encrypted at rest?” and “Are access controls enforced server-side?” and you answer yes, because you believe so, because your developers are good people, and because no is not an answer that closes deals.

Then, somewhere around question 30, the honest thought arrives: I don’t actually know if these answers are true.

This checklist exists for that moment. It is the 25 controls we verify as a custom web development company in the USA market before we let anything we build face the internet, grouped into six layers, each with the attack it prevents, a verification you can run in about an hour, and the specific way teams get it wrong while believing they got it right.

Why Security Questionnaires Expose More Than Penetration Tests

A penetration test is a snapshot: skilled people attack the application for a week and report what broke. It is valuable, and it answers a narrow question: what could this team exploit, this week. A questionnaire asks a more revealing one: do you know your own security posture? “Is data encrypted at rest?” has three possible states: yes, no, and the most dangerous one, “we assume so.” Questionnaires are embarrassing precisely because they expose the third state, and the third state is where breaches live.

Security researcher Bruce Schneier compressed the whole discipline into seven words:

“Security is a process, not a product.”

Bruce Schneier, The Process of Security (2000)

The process, concretely, is verification with a name and a date attached. That is all this checklist asks: 25 controls, each moved from “assumed” to “checked.” Here is the map.

Layer 1: Authentication and Sessions (Controls 1-5)

Authentication is the front door, and attackers rarely pick the lock; they try keys stolen from somewhere else. These five controls assume credential-stuffing lists and phished passwords are already in play, because they are.

Layer 2: Authorization (Controls 6-9)

This layer deserves its own headline. In the OWASP Top 10:2025, broken access control holds the #1 position, with 100% of applications tested showing some form of it, up from 94% in the 2021 edition. The most common critical flaw in web applications is not an exotic exploit. It is an authorization check that simply is not there: the UI hides the button, and the API behind it never asks who’s calling.

If you verify only one layer before launch, verify this one. It is where a SaaS development company earns its keep on multi-tenant builds, because control 9 is a discipline applied to every query ever written, not a setting.

Layer 3: Data (Controls 10-14)

Data controls decide the blast radius: whether an intrusion becomes an incident report or a regulatory event. IBM’s global average breach cost of $4.88 million is mostly made of this layer’s failures.

Layer 4: Dependencies (Controls 15-18)

Your application is mostly other people’s code: framework, packages, and increasingly, AI-generated snippets. This is the layer most teams skip entirely, and OWASP has ranked vulnerable and outdated components as a top-ten risk in every recent edition.

Control 17 is the 2026 addition to a classic list. AI assistants produce code that compiles, reads cleanly, and reproduces the average security of its training data; the risk mechanics are the ones we unpacked in why MVP speed is meaningless without technical credibility. Generated code is a draft from a stranger, and it gets a stranger’s code review.

Layer 5: Infrastructure (Controls 19-22)

Layer 6: Monitoring and Incident Readiness (Controls 23-25)

The last layer accepts an uncomfortable premise: something will eventually get through. What separates a contained incident from a $4.88 million one is how fast you notice and how prepared the first hour is.

The Pre-Launch Sign-Off Sheet

The checklist becomes a governance tool with one addition: a name and a date. Before launch, each layer gets an accountable owner who verifies its controls and signs. “Mostly verified” is a finding, not a pass; a control that fails verification is a ticket, not a footnote. Kept in the repo and re-run at every major release, this sheet is also the honest answer to the next security questionnaire: not “yes,” but “verified, on this date, by this person,” which is the answer enterprise buyers are actually probing for.

One honest caveat about scope: these 25 controls are the launch baseline for a typical web application, the floor that makes you a hard target rather than an easy one. Regulated industries add layers on top (HIPAA, PCI DSS, SOC 2 have their own regimes), and none of this replaces periodic penetration testing; it makes the pen test worth its fee, because the findings will be interesting instead of embarrassing. And the economics compound quietly: skipping these controls is the security version of the pattern we mapped in the hidden APR of cheap code, a discount at build time financed at breach-time interest rates.

FAQs

Is this checklist a replacement for a penetration test?

No, it’s the prerequisite. A pen test on an application that hasn’t verified these 25 controls produces a long list of known issues you paid to rediscover. Verify the baseline first, then let the pen test hunt for what a checklist can’t catch: logic flaws, chained exploits, and your specific blind spots.

Which security controls should we verify first?

Authorization (controls 6 through 9). Broken access control is ranked #1 in the OWASP Top 10:2025, with 100% of tested applications showing some form of it. It’s also among the cheapest to test: an afternoon of changing IDs and calling admin endpoints as a normal user reveals most of it.

How long does it take to verify all 25 controls?

Each control is designed to be verifiable in about an hour, so a focused week covers the list for a typical application. The first pass is the slow one; subsequent releases only re-verify what changed, plus a quarterly full pass.

Do these controls cover SaaS security requirements for enterprise deals?

They cover the technical majority of what questionnaires ask, especially with the sign-off sheet as evidence. Enterprise deals often add organizational requirements (SOC 2, policies, vendor management) that sit on top of this baseline rather than replacing it. Passing the technical layer is what makes the rest a paperwork exercise instead of an engineering scramble.

Is AI-generated code a real security risk or a hypothetical one?

Real, and mechanical: generated code reproduces the average patterns of its training data, including insecure ones, at a speed that outruns casual review. Control 17 treats it accordingly: the same review and static analysis as code from a stranger, because that is what it is. A web development services partner using AI tooling should be able to show you that review step in their process.

Sources

• OWASP Top 10:2025, A01 Broken Access Control
• OWASP Top 10:2021, A01 Broken Access Control (94% of tested applications)
• IBM, Cost of a Data Breach Report 2024
• Bruce Schneier, The Process of Security (2000)

Looking for timeline and cost estimates for your app?

Contact us

Hemagini Jain

Hemangini Jain is a Co-Founder at Techuz, where she helps startups turn ideas into market-ready SaaS products often in 16 weeks or less. She's worked with founders behind $10M+ success stories and enjoys writing about MVP development, AI, product strategy, and what it really takes to launch.