You probably cannot read your application's code, and you do not need to. What you can do is ask your developers a short set of questions and listen carefully to the answers. This web application security checklist gives you twelve of them, grouped by the kind of risk they cover, with notes on what a good answer sounds like.
The questions follow the risks in the OWASP Top 10:2025, a widely used reference list of web application security risks, but they are written for business owners and managers rather than security specialists.
How to use this web application security checklist
Ask in writing, and keep the answers. A good answer is specific: it names the mechanism, says where it lives in the code or infrastructure, and admits gaps. A weak answer is general: "it's secure," "the framework handles that," "we'll look at security before launch."
Here is the difference on one question for a hypothetical clinic booking app. Asked how one patient is prevented from seeing another patient's appointments:
- Weak: "Users have to log in, so only they can see their data."
- Strong: "Every appointment query is scoped to the logged-in patient, and each controller action checks a policy. We have tests that log in as one patient and try to open another patient's appointment by ID; they must get a 403 or 404."
The first answer describes authentication. The second describes authorization, which is the part that actually protects the data.
Who can see and do what
1. How do you stop one user from seeing another user's data?
Broken access control is A01 in the 2025 list, the same first place it held in 2021, and server-side request forgery is now part of the same category. The classic example: a customer opens /invoices/1043, changes it to /invoices/1044 and sees a stranger's invoice. Listen for server-side checks on every request, not just hidden buttons in the interface, and tests that try this on purpose.
2. How are admin and staff accounts protected?
Admin accounts are the most valuable target. Good answers include multi-factor authentication for anyone with admin access, separate accounts for each person rather than one shared login, roles that give each person only what they need, rate limiting on login attempts, and a record of who changed what.
3. How are passwords stored?
The answer should be "hashed with a slow, salted algorithm," never "encrypted" (which means someone can decrypt them) and never a fast hash such as MD5 or SHA-1. OWASP's Password Storage Cheat Sheet recommends Argon2id, with bcrypt acceptable for legacy systems at a work factor of 10 or more. Laravel, for example, uses bcrypt by default and supports Argon2id.
Data, input and secrets
4. How do you handle what users type and upload?
Injection is still on the list at A05. Good answers mention parameterized queries or the framework's query builder instead of building SQL from strings, escaping output in templates, validating input on the server, and treating uploads carefully: checking file type and size, renaming files, and storing them where they cannot be executed or opened by guessing a URL.
5. What data are we storing that we do not need?
Data you do not hold cannot leak. Ask which personal fields are collected, why, and how long they are kept. Card numbers should normally never touch your servers; a payment provider's hosted checkout or tokens keep them out of your database entirely.
6. Where do secrets such as API keys and database passwords live?
Not in the code repository, and not in a chat message. Listen for environment files or a secrets manager kept outside version control, different keys for staging and production, and a habit of rotating keys when someone leaves the team.
Configuration and dependencies
7. What is different about how production is configured?
Security misconfiguration is A02. Production should have debug mode off, HTTPS everywhere, security headers set, and error pages that say "something went wrong" without showing stack traces or file paths. Laravel's documentation warns that leaving APP_DEBUG on in production risks exposing sensitive configuration values to users. The 2025 list also adds A10, Mishandling of Exceptional Conditions, which is about how the app behaves when things fail, so ask what happens when the payment provider times out or the database is unreachable.
8. How do you keep libraries up to date, and who watches for security advisories?
Software Supply Chain Failures is new at A03 in 2025, expanding the older category about vulnerable components. A modern app often includes hundreds of third-party packages, and each is someone else's code running inside yours. Good answers mention committed lockfiles, a regular update schedule, and automated checks such as composer audit, which checks installed PHP packages against security advisories and flags abandoned ones, or npm audit for JavaScript.
When something goes wrong
9. Would we know if someone was attacking us?
A09 in the 2025 list is Security Logging and Alerting Failures. Ask what gets logged (logins, failed logins, password resets, permission changes, large exports), where logs are kept, and who is alerted when something unusual happens, such as hundreds of failed logins in a few minutes. Logs nobody reads only help after the damage is done.
10. If the database disappeared tonight, what would we restore, and how long would it take?
Listen for automatic backups stored away from the main server, encrypted, with a defined retention period, and above all a date when someone last restored one successfully. Until someone has restored a backup, nobody knows whether it works. For an online store taking orders all day, "we can restore last night's backup" means losing up to a day of orders; that may or may not be acceptable, but you should decide it knowingly.
11. If a developer's laptop were stolen tomorrow, what would we do?
The answer tests how access is managed. Good signs: multi-factor authentication on the code host and cloud accounts, personal accounts instead of shared ones, a list of who has access to what, and the ability to revoke one person's access in minutes. This overlaps with ownership questions covered in our source code ownership and handover checklist; the business should control the accounts, not an individual.
Proof, not promises
12. How is security tested before release, and when did someone else last test it?
Good answers describe layers: code review that looks for access control and input handling, automated dependency and code checks on every pull request, and for apps handling sensitive data, a periodic test by someone outside the team. OWASP's Application Security Verification Standard (the latest stable release is 5.0.0) is a useful reference here, because it turns "is it secure?" into specific, checkable requirements. Security checks belong in the same risk-based plan as the rest of your testing, described in our guide to software testing on a budget.
What to do with the answers
Mark each answer as clear, partial or missing. Fix missing answers on the questions that protect money and personal data first, usually 1, 2, 6 and 10, then work down the list.
For example, say the clinic app's developer answers questions 1, 3 and 4 clearly, gives partial answers on 2 and 8 (multi-factor authentication exists but is optional for staff; libraries are updated "when something breaks"), and has no answer at all for 10. The order of work is then clear: restore a backup to a test server this week, make multi-factor authentication mandatory for staff, and put a monthly dependency update and audit on the calendar. Keep this web application security checklist with the answers and ask again in six months; the answers should get more specific, not less.
Not every site needs all twelve. If yours is a brochure site with no logins, no payments and no customer data, focus on three things: keep the CMS and plugins updated, protect the admin login with multi-factor authentication, and keep tested backups. For a site like that, those three cover most of the realistic risk.
If the answers you get are vague, or you want an independent view, our cybersecurity team can review your application against these questions and give you a plain-language list of what to fix first, or you can start with a short conversation. Our security and compliance page has more on how we approach this in our own work.
