{"id":8901,"date":"2026-09-10T13:47:38","date_gmt":"2026-09-10T08:17:38","guid":{"rendered":"https:\/\/www.techuz.com\/blog\/?p=8901"},"modified":"2026-09-15T03:52:52","modified_gmt":"2026-09-14T22:22:52","slug":"web-application-security-checklist","status":"publish","type":"post","link":"https:\/\/www.techuz.com\/blog\/web-application-security-checklist\/","title":{"rendered":"The Web Application Security Checklist: 25 Controls to Verify Before Launch"},"content":{"rendered":"
\n

Quick Answer:<\/strong> A web application is ready to launch when 25 controls across six layers (authentication, authorization, data, dependencies, infrastructure, and monitoring) have each been verified by someone, on purpose, recently. Not assumed. Verified.<\/p>\n

The priority order is not guesswork: broken access control holds the #1 spot in the OWASP Top 10:2025, where 100% of applications tested showed some form of it<\/a>, and IBM puts the global average cost of a data breach at $4.88 million<\/a>. Every control below includes what it protects against, how to verify it in about an hour, and the common way it’s done wrong, so a technical founder can turn “I think so” into “checked, on this date, by this person.”<\/p>\n<\/div>\n

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.<\/p>\n

Then, somewhere around question 30, the honest thought arrives: I don’t actually know if these answers are true.<\/em><\/p>\n

This checklist exists for that moment. It is the 25 controls we verify as a custom web development company in the USA<\/a> 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.<\/p>\n

Why Security Questionnaires Expose More Than Penetration Tests<\/h2>\n

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?<\/em> “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.<\/p>\n

Security researcher Bruce Schneier compressed the whole discipline into seven words:<\/p>\n

\n

“Security is a process, not a product.”<\/p>\n

Bruce Schneier, The Process of Security (2000)<\/p>\n<\/blockquote>\n

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.<\/p>\n

\n\"25
\n<\/figure>\n

Layer 1: Authentication and Sessions (Controls 1-5)<\/h2>\n

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.<\/p>\n\n\n\n\n\n\n\n\n\n
Control<\/th>\nProtects against<\/th>\nVerify in an hour<\/th>\nCommon failure<\/th>\n<\/tr>\n<\/thead>\n
1. Modern password hashing<\/strong> (bcrypt, scrypt, or Argon2)<\/td>\nA stolen database becoming usable passwords<\/td>\nLook at one stored hash: it should start with $2b$, $argon2, or similar<\/td>\nMD5\/SHA-1, or a homemade scheme from an old tutorial<\/td>\n<\/tr>\n
2. MFA available, enforced for admins<\/strong><\/td>\nAccount takeover with a phished or reused password<\/td>\nTry to log into an admin account with password alone<\/td>\nMFA offered to users, admin panel exempt “for convenience”<\/td>\n<\/tr>\n
3. Rate limiting and lockout on auth endpoints<\/strong><\/td>\nCredential stuffing and brute force<\/td>\nScript 50 rapid login attempts against staging; count how many are processed<\/td>\nThe login form is limited, the API endpoint behind it isn’t<\/td>\n<\/tr>\n
4. Session expiry and rotation<\/strong><\/td>\nHijacked sessions living forever<\/td>\nChange the password in one browser; confirm the session in a second browser dies<\/td>\nTokens that never expire and survive password changes<\/td>\n<\/tr>\n
5. Secure cookie flags<\/strong> (HttpOnly, Secure, SameSite)<\/td>\nToken theft via XSS; cross-site request forgery<\/td>\nOpen devtools, inspect the session cookie’s flags<\/td>\nThe session token in localStorage, readable by any injected script<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Layer 2: Authorization (Controls 6-9)<\/h2>\n

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<\/a>, 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.<\/p>\n

\n\"The
\n<\/figure>\n\n\n\n\n\n\n\n\n
Control<\/th>\nProtects against<\/th>\nVerify in an hour<\/th>\nCommon failure<\/th>\n<\/tr>\n<\/thead>\n
6. Server-side authorization on every endpoint<\/strong><\/td>\nForced browsing to functions the UI hides<\/td>\nAs a low-privilege user, call three admin API routes directly<\/td>\nAuthorization lives in the frontend; the API trusts whoever arrives<\/td>\n<\/tr>\n
7. Object-level ownership checks<\/strong><\/td>\nIDOR: reading someone else’s records by changing an ID<\/td>\nLog in as user A, request user B’s invoice by ID<\/td>\nSequential IDs plus a lookup that never checks the owner<\/td>\n<\/tr>\n
8. Server-side role checks for admin functions<\/strong><\/td>\nVertical privilege escalation<\/td>\nEdit your role claim client-side; see if the server honors it<\/td>\nThe role read from a client-modifiable token, unverified<\/td>\n<\/tr>\n
9. Tenant isolation in every query<\/strong><\/td>\nCross-tenant data leaks in multi-tenant apps<\/td>\nFrom tenant A, attempt to fetch tenant B’s data on staging<\/td>\nOne query, somewhere, missing the tenant scope<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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

Layer 3: Data (Controls 10-14)<\/h2>\n

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<\/a> is mostly made of this layer’s failures.<\/p>\n\n\n\n\n\n\n\n\n\n
Control<\/th>\nProtects against<\/th>\nVerify in an hour<\/th>\nCommon failure<\/th>\n<\/tr>\n<\/thead>\n
10. TLS everywhere, with HSTS<\/strong><\/td>\nInterception and downgrade attacks<\/td>\nRun an SSL Labs scan; try an http:\/\/ URL and confirm the redirect<\/td>\nTLS at the load balancer, plaintext between internal services<\/td>\n<\/tr>\n
11. Encryption at rest, including backups<\/strong><\/td>\nStolen disks, snapshots, and backup files<\/td>\nCheck the database and the backup storage settings, separately<\/td>\nProduction encrypted; the S3 bucket of backups, not<\/td>\n<\/tr>\n
12. Secrets in a manager, not in code<\/strong><\/td>\nLeaked API keys and database credentials<\/td>\nRun a secrets scanner (gitleaks, trufflehog) over the repo and its history<\/td>\nThe .env file that was committed once, three years ago, and lives in history forever<\/td>\n<\/tr>\n
13. PII inventory, minimization, and log hygiene<\/strong><\/td>\nOversized breach impact; GDPR and privacy exposure<\/td>\nList every PII field you store; grep the logs for emails and tokens<\/td>\nFull request bodies, PII included, sitting in application logs<\/td>\n<\/tr>\n
14. Backups that restore<\/strong><\/td>\nRansomware and data loss becoming extinction events<\/td>\nRestore last night’s backup to staging; time it<\/td>\nBackups taken daily for years, restored never<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

Staring down a security questionnaire right now?<\/p>\n

Techuz runs pre-launch security reviews against this exact checklist: every control verified, evidence collected, and a report you can attach to the questionnaire instead of hoping.<\/p>\n

Request a security review<\/a>\n<\/p><\/div>\n

Layer 4: Dependencies (Controls 15-18)<\/h2>\n

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.<\/p>\n\n\n\n\n\n\n\n\n
Control<\/th>\nProtects against<\/th>\nVerify in an hour<\/th>\nCommon failure<\/th>\n<\/tr>\n<\/thead>\n
15. Automated dependency scanning in CI<\/strong><\/td>\nShipping packages with known CVEs<\/td>\nOpen the last five scanner alerts; check who closed them, and when<\/td>\nAlerts enabled, assigned to nobody, 400 unread<\/td>\n<\/tr>\n
16. Lockfiles and pinned versions<\/strong><\/td>\nBuilds silently pulling different, compromised versions<\/td>\nConfirm the lockfile is committed and CI installs from it<\/td>\nVersion ranges that resolve differently in prod than on laptops<\/td>\n<\/tr>\n
17. Review of AI-generated and pasted code<\/strong><\/td>\nInsecure patterns entering at generation speed<\/td>\nSample five recent AI-assisted PRs; run SAST over auth and input paths<\/td>\nGenerated auth code trusted because it looked idiomatic<\/td>\n<\/tr>\n
18. Least-privilege keys for third-party services<\/strong><\/td>\nOne compromised vendor unlocking everything<\/td>\nList every external API key and what it’s scoped to<\/td>\nA single god-key with full permissions, shared across services<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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<\/a>. Generated code is a draft from a stranger, and it gets a stranger’s code review.<\/p>\n

Layer 5: Infrastructure (Controls 19-22)<\/h2>\n\n\n\n\n\n\n\n\n
Control<\/th>\nProtects against<\/th>\nVerify in an hour<\/th>\nCommon failure<\/th>\n<\/tr>\n<\/thead>\n
19. Security headers<\/strong> (CSP, X-Frame-Options, and peers)<\/td>\nXSS amplification and clickjacking<\/td>\nRun the site through securityheaders.com; read the grade<\/td>\nWhatever the framework shipped by default, unreviewed<\/td>\n<\/tr>\n
20. Parameterized queries everywhere<\/strong><\/td>\nSQL and query injection<\/td>\nGrep for string-concatenated queries; run sqlmap against staging forms<\/td>\nThe ORM used everywhere except one legacy raw query<\/td>\n<\/tr>\n
21. File upload restrictions<\/strong><\/td>\nRemote code execution via uploaded files<\/td>\nTry uploading a script file with a doctored extension; check where files are stored<\/td>\nClient-side extension checks; uploads served from the webroot<\/td>\n<\/tr>\n
22. Environment separation<\/strong><\/td>\nProduction data and credentials leaking through dev<\/td>\nCheck what data staging holds and who can reach it<\/td>\nA full production copy on every developer laptop<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Layer 6: Monitoring and Incident Readiness (Controls 23-25)<\/h2>\n

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.<\/p>\n\n\n\n\n\n\n\n
Control<\/th>\nProtects against<\/th>\nVerify in an hour<\/th>\nCommon failure<\/th>\n<\/tr>\n<\/thead>\n
23. Centralized security logging<\/strong><\/td>\nBlind forensics; attackers erasing their tracks<\/td>\nFail five logins, then find them in the log platform<\/td>\nLogs stored only on the server that just got compromised<\/td>\n<\/tr>\n
24. Alerting a human actually receives<\/strong><\/td>\nBreaches discovered by customers or journalists<\/td>\nFire a test alert; confirm who was paged and how fast<\/td>\nBeautiful dashboards that no one is watching at 2 a.m.<\/td>\n<\/tr>\n
25. A one-page incident response plan<\/strong><\/td>\nChaos, delay, and legal missteps in the first hour<\/td>\nRun a 30-minute tabletop: “we think customer data is leaking, go”<\/td>\nThe plan exists in one senior engineer’s head, and they’re on holiday<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The Pre-Launch Sign-Off Sheet<\/h2>\n

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.<\/p>\n

\n\"The
\n<\/figure>\n

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>, a discount at build time financed at breach-time interest rates.<\/p>\n

\n

Launch with the sheet already signed<\/p>\n

Techuz builds with these controls in the definition of done, not bolted on before the questionnaire arrives. That’s what secure custom web development<\/a> means in practice: evidence, not assurances.<\/p>\n

Start a conversation<\/a>\n<\/p><\/div>\n

FAQs<\/h2>\n

Is this checklist a replacement for a penetration test?<\/h3>\n

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.<\/p>\n

Which security controls should we verify first?<\/h3>\n

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.<\/p>\n

How long does it take to verify all 25 controls?<\/h3>\n

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.<\/p>\n

Do these controls cover SaaS security requirements for enterprise deals?<\/h3>\n

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.<\/p>\n

Is AI-generated code a real security risk or a hypothetical one?<\/h3>\n

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<\/a> partner using AI tooling should be able to show you that review step in their process.<\/p>\n

Sources<\/h2>\n