Web Application Security Checklist for Business Owners: What to Ask Your Developers

If you own or manage a web application, you carry the consequences of a security failure even if you never see the code. Customers, regulators and insurers will come to you, not to the developer who wrote the login page. The difficulty is that most security advice is written for engineers, so non-technical owners end up accepting "yes, it is secure" as an answer.

This web application security checklist turns the current OWASP Top 10 into plain questions you can put to an in-house team or an outside agency, with a note on what a credible answer sounds like. It also covers the baseline schemes buyers in the UK and US recognize, when to commission a penetration test, and what the law broadly expects of you after a breach.

Quick answer

You do not need to understand the code to check whether security is being taken seriously. Ask your developers specific questions in nine areas: access control, data protection, dependencies and updates, input handling, logging and alerting, backups and recovery, hosting configuration, secrets management and third-party scripts. A good team answers with evidence: a named tool, a document, a test result, a date. A weak team answers with reassurance. Back the answers up with an independent penetration test before launch and after major changes, and agree in writing who tells whom, and how fast, if something goes wrong.

What the OWASP Top 10 is, and what the 2025 edition changed

The OWASP Top 10 is, in OWASP's words, "a standard awareness document for developers and web application security" that reflects broad consensus on the most critical risks to web applications. The OWASP project page states that the most current released version is the OWASP Top 10 2025, and the full list is published here.

According to the 2025 introduction, the notable changes from the 2021 edition are a new category for mishandling of exceptional conditions (errors and failures), a widening of the old "vulnerable components" category into software supply chain failures, security misconfiguration moving up to second place, and server-side request forgery being folded into broken access control. If your developers still quote the 2021 list, that is not a problem in itself, but it is a fair prompt to ask how they keep up.

The table maps each 2025 category to the part of this checklist where it is covered.

The checklist: what to ask, area by area

1. Authentication and access control

Authentication is proving who a user is. Access control is deciding what that user may do. Broken access control sits at the top of the 2025 list.

• Is multi-factor authentication available to all users and mandatory for administrators? OWASP recommends enforcing it, and CISA advises businesses to aim for phishing-resistant methods, noting that text and email codes give the weakest protection.
• If customer A changes the ID in a web address to customer B's ID, what happens? The answer should be that the server checks ownership of every record on every request. OWASP's guidance is to deny by default and enforce checks in server-side code, not in the browser.
• Are failed logins limited, and are new passwords checked against known breached passwords?
• Who has admin access today, including former staff and contractors, and when was that list last reviewed?

2. Data protection and encryption

• What personal or sensitive data do we store, and do we need all of it? OWASP puts it bluntly: do not store sensitive data unnecessarily, because data you do not keep cannot be stolen.
• Is all traffic encrypted in transit and is sensitive data encrypted at rest? Expect a specific answer: TLS 1.2 or later everywhere, and encryption on the database, file storage and backups.
• How are passwords stored? The only acceptable answer is a salted, purpose-built password hashing function. "Encrypted" or "in the database" is a red flag.
• Is real customer data ever copied to test systems or developer laptops?

3. Dependencies and updates

A modern web application is mostly other people's code: frameworks, libraries and plugins. OWASP describes supply chain failures as breakdowns or compromises in building, distributing or updating software.

• Can you give me a list of every third-party component in the application and its version? This list is called a software bill of materials (SBOM). A team that can produce one quickly is tracking its dependencies.
• How do you find out when one of those components has a known vulnerability, and how quickly do you patch? Look for an automated scanner plus an agreed timescale for critical fixes.
• Who applies security updates after the project ends, and is that in the contract? This is the most common gap in fixed-price builds. Our guide to outsourcing software development from the US and UK covers what to put in the agreement.

4. Input handling and error behavior

Every form field, search box, file upload and API call is a way for an attacker to send your system something unexpected. Injection happens when that input is executed as a command, for example against your database.

• Do all database queries use parameterized queries or the framework's query builder? The answer should be "yes, everywhere", with exceptions listed and justified.
• Is input validated on the server, not only in the browser? Browser checks improve usability; they do not stop an attacker.
• How are file uploads restricted by type, size and storage location?
• When something fails halfway, for example a payment step, does the system stop safely or carry on? The new A10 category exists because applications that "fail open" or leave half-finished transactions create vulnerabilities.

5. Logging and monitoring

OWASP's position is that without logging and monitoring, attacks cannot be detected, and without alerting it is very hard to respond quickly.

• Are logins, failed logins, permission failures and high-value actions logged?
• Who receives an alert when something suspicious happens, and at what hours? A log nobody reads is a record, not a control.
• How long are logs kept, and could an attacker who gets into the server delete them?

6. Backups and recovery

• What is backed up, how often, and where? CISA's #StopRansomware Guide advises keeping offline, encrypted backups, because ransomware often seeks out and destroys backups it can reach.
• When did you last restore from a backup as a test, and how long did it take? If the answer is "never", you have an assumption, not a backup.
• How much data could we lose in the worst case, and how long would we be offline? These two numbers are business decisions. You should set them, not inherit them.

7. Hosting configuration

Security misconfiguration means a system, application or cloud service has been set up incorrectly from a security point of view. OWASP's examples include unchanged default accounts, unnecessary features left switched on, detailed error messages shown to users and overly permissive cloud storage.

• Are any storage buckets, databases or admin panels reachable from the public internet, and why?
• Do error pages shown to users reveal technical detail?
• Are the test and live environments separate, and built the same repeatable way?
• Whose name is on the hosting, domain and cloud accounts? They should be yours, with the developer granted access, not the reverse.

8. Secrets management

Secrets are the passwords, API keys and encryption keys the application uses to talk to databases, payment providers and other services.

• Are any secrets stored in the source code or the code repository? The answer must be no. OWASP advises against hardcoded secrets and against keeping keys in code repositories.
• Where are they stored instead, and who can read them? Expect a named secrets manager or the hosting platform's equivalent.
• If a developer leaves tomorrow, what do we rotate, and how long does it take?

9. Third-party scripts

Analytics tags, chat widgets, ad pixels and payment scripts run inside your pages with access to what your users type. OWASP flags reliance on code from untrusted sources and content delivery networks as an integrity risk.

• Can I see a list of every external script loaded on our site, who added it and why?
• Which of them load on login, checkout or account pages? Fewer is better.
• Do we use browser controls to limit them? One example is Subresource Integrity, which lets the browser verify that a fetched file has not been unexpectedly changed.

Baseline schemes buyers recognize: Cyber Essentials and NIST

These schemes describe how an organization manages security in general. They complement the checklist above; they do not replace it.

Two practical points. First, UK central government procurement policy (PPN 014) covers Cyber Essentials for contracts with certain characteristics, such as suppliers handling citizens' personal information, and states that suppliers must recertify every 12 months. Second, Cyber Essentials assesses an organization's own IT against five controls. A certificate held by you or your supplier is a useful signal, but it is not a review of the code in an application built for you.

Penetration testing: what it is and when to commission one

The NCSC defines penetration testing as a method for gaining assurance in the security of an IT system by attempting to breach some or all of that system's security, using the same tools and techniques as an adversary might. In practice, you pay an independent specialist to attack your application with permission and report what they found.

The NCSC is clear about the limits. A test should confirm that your own vulnerability management is working, not serve as the main way you find problems, and it can only show that a system is not vulnerable to known issues on the day of the test.

Reasonable moments to commission one:

• Before the first public launch of an application that handles personal or payment data.
• After a major change, such as a new login system, payment flow, API or hosting move.
• On a regular cycle agreed with your risk appetite, customers or insurer.
• When an enterprise customer or regulator asks for evidence.

Use a tester who is independent of the team that built the system, agree the scope in writing, ask for findings ranked by severity, and budget for a retest after fixes. Cost depends mainly on scope: the number of user roles, screens, APIs and integrations, and whether the tester is given accounts and documentation.

If a breach happens: notification duties at a high level

This section is general information, not legal advice. Take advice from a qualified lawyer for your situation.

United Kingdom

Under UK data protection law, the ICO's guidance says a personal data breach that is likely to pose a risk to people's rights and freedoms must be reported to the ICO without undue delay and not later than 72 hours after you become aware of it. If the risk is high, you must also tell the affected individuals without undue delay. You must keep a record of all breaches, including those you decide not to report. If a supplier acting as your processor suffers a breach, it must inform you without undue delay.

United States

The starting point is state law. The FTC's Data Breach Response guide notes that all states, the District of Columbia, Puerto Rico and the Virgin Islands have enacted legislation requiring notification of security breaches involving personal information. Sector rules can apply on top. The FTC's Health Breach Notification Rule covers apps, websites and connected devices holding consumers' health information that are not covered by HIPAA, and requires notice to affected consumers, the FTC and in some cases the media. HIPAA-covered organizations have their own notification duties to the Department of Health and Human Services.

The question for your developers and hosting provider is therefore contractual: how quickly must you tell us about a suspected incident, and who is the named contact? A 72-hour clock is hard to meet if your supplier takes a week to mention it.

For technical readers

• Design. OWASP's A06 guidance recommends threat modeling for authentication, access control, business logic and key flows. Insecure design cannot be fixed by good implementation alone.
• Access control. Implement it once, reuse it, deny by default, and cover it with functional tests in the unit and integration suites.
• Cryptography. OWASP names Argon2, yescrypt, scrypt and PBKDF2-HMAC-SHA-512 for password hashing, TLS 1.2 or later with forward secrecy, and HSTS.
• Supply chain. Generate an SBOM covering transitive dependencies, monitor vulnerability databases, prefer signed packages, and harden CI/CD with separation of duties, environment-scoped secrets and tamper-evident logs.
• Errors. Use a global exception handler, roll back failed transactions (fail closed), and apply rate limits and resource quotas.
• Process. NIST's Secure Software Development Framework (SP 800-218) describes practices that can be added to any development life cycle.

FAQ

Is the OWASP Top 10 a standard my application can be certified against?

No. OWASP describes it as an awareness document. It is a sound minimum reference for developers and testers, but there is no official "OWASP certified" status for an application. Treat any such claim with caution and ask what was actually tested.

Our site runs on WordPress or another off-the-shelf platform. Does this checklist still apply?

Yes. The emphasis shifts toward dependencies and updates (core, themes and plugins), admin access, hosting configuration and backups, because you write less custom code but rely on more third-party components.

Does a Cyber Essentials certificate mean my web application is secure?

Not on its own. It shows an organization has five baseline controls in place across its IT. It does not examine the design or code of a custom application, which is what the checklist questions and a penetration test are for.

How often should we run a penetration test?

There is no single rule that fits every business. Test before launch and after significant changes, then on a cycle that reflects how sensitive the data is, how often the application changes, and what customers, insurers or regulators require. Remember the NCSC's point that a test reflects one day only.

Who is responsible if my developers or hosting provider cause a breach?

Under UK rules described by the ICO, a processor must inform you of a breach, and the reporting duty to the regulator sits with you as the controller. US obligations vary by state and sector. In both countries, responsibilities, notification times and liability between you and a supplier should be set out in the contract. Take legal advice on the wording.

What if my developers cannot answer these questions?

Treat gaps as findings, not as failure. Ask for a written plan with owners and dates for each unanswered item, starting with access control, backups and updates. Persistent vagueness after that is a reason to seek an independent review.

Conclusion and next step

Security you cannot inspect has to be managed through questions, evidence and independent testing. The OWASP Top 10:2025 gives you the agenda, the nine areas above turn it into a conversation, and schemes such as Cyber Essentials and the NIST Cybersecurity Framework give you a recognized baseline for the organization around the application.

A practical next step is to send the questions to whoever maintains your application and ask for written answers within two weeks, with evidence where it exists. Rank the gaps by how much damage each could do, and fix those first. If you are planning a new build or taking over an existing one and want these points addressed in the specification from day one, Entrant Technologies builds web applications and custom software, and you can get in touch to talk through your requirements.