Web Application Security Checklist for Business Owners

Most break-ins are not clever. They use a weak password, an admin page anyone can reach, or a library nobody updated. This checklist is written for business owners and product managers. Use it to ask your developer or vendor the right questions before launch, and to check an application that is already live.

Quick answer

• Protect admin accounts with two-factor authentication.
• Check every page and API for access control, not just the menu.
• Keep the server, framework and libraries updated on a schedule.
• Take automatic backups and test restoring them.
• Turn on monitoring and logs so you know when something goes wrong.

1. Logins and accounts

• Passwords are stored using a modern hashing method, never as plain text.
• Two-factor authentication for every admin and staff account.
• Limits on repeated login attempts, to slow down password guessing.
• Password reset links that expire and work only once.
• Sessions that time out, and a way to log out of all devices.

2. Access control

This is the most common serious flaw in business applications. Hiding a button is not security. The server must check, on every request, whether this user is allowed to see or change this record.

• A customer cannot open another customer's invoice by changing a number in the URL.
• Staff roles only see the data they need.
• Admin panels are not reachable by guessing the address, and ideally are limited by IP address or VPN.
• Every API endpoint applies the same rules as the screens.

3. Data protection

• HTTPS everywhere, with automatic certificate renewal.
• Sensitive fields, such as ID numbers, are encrypted in the database.
• Only collect personal data you actually need, and know where it is stored. India's Digital Personal Data Protection Act, 2023 expects organisations to take reasonable security safeguards to protect personal data.
• Uploaded files are checked for type and size, and are not stored where they can run as code.
• Card payments are handled by the payment gateway, so card numbers never touch your server.

4. Input and common attacks

Ask your developer how the application handles the well-known attack types in the OWASP Top 10, a widely used list of the most critical web application security risks. At minimum:

• Database queries use parameterised queries or an ORM, which prevents SQL injection.
• User content is escaped before display, which prevents cross-site scripting.
• Forms that change data are protected against cross-site request forgery.
• Error messages shown to users do not reveal code, file paths or database details.

5. Updates and dependencies

Modern applications rely on hundreds of open-source packages. Vulnerabilities in them are found every week, and sometimes in the language runtime itself, as our article on the PHP2Shell vulnerability shows.

• A named person is responsible for security updates.
• Dependencies are scanned automatically for known vulnerabilities.
• The server operating system and language runtime are on supported versions.
• Critical patches are applied within days, not at the next planned release.

6. Backups and recovery

• Automatic daily backups of the database and uploaded files.
• At least one copy stored separately from the main server.
• A restore test at least every quarter. A backup you have never restored is a guess.
• A written plan for who does what if the site goes down or is compromised.

7. Monitoring and incident response

• Uptime monitoring with alerts to a real person.
• Logs of logins, admin actions and errors, kept for a sensible period.
• Alerts for unusual activity, such as many failed logins or bulk data exports.
• Know your reporting duties. In India, CERT-In requires many types of cyber security incidents to be reported within six hours of noticing them.

8. Bots and automated traffic

Login, signup and contact forms attract automated abuse. Use rate limiting and a bot challenge where needed, and decide which crawlers and AI agents you allow. Our article on bot traffic rules explains how to think about it.

Questions to ask your developer

1. How do you check access control on every request and API?
2. Which dependencies does the application use, and how are they kept updated?
3. Where are backups stored, and when did we last test a restore?
4. What would we see, and who would be alerted, if someone broke in tonight?
5. Has the application had a security review or penetration test?

Frequently asked questions

What is the most common security problem in business web applications?

Broken access control: the application shows or changes data the user should not have access to, often by changing an ID in the URL or calling an API directly. It ranks at the top of the OWASP Top 10 list of web application security risks.

How often should a web application get security updates?

Check for dependency and server updates at least monthly, and apply critical security patches within days of release. Plan framework upgrades every quarter so they never become a large migration.

Do small businesses need a penetration test?

If the application handles personal data, payments or business-critical operations, a penetration test before launch and after major changes is worth it. For smaller sites, a code review plus automated scanning and good update habits cover most risks.