The Web App Security Checklist Every Business Should Demand

Most security failures are not exotic. They are boring, preventable mistakes: a database left open to the internet, a password reset link that never expires, an API key committed to a public repository. As a founder, you do not need to read source code to catch these. You need a web app security checklist and the confidence to ask whether each item is actually done.

This is that checklist. It is written so you can sit across from your development team, go line by line, and get straight answers. If a question produces hesitation or jargon meant to make you stop asking, that is information too.

Authentication and access control

Authentication is who the user is. Authorization is what they are allowed to do. Both go wrong in predictable ways.

• Passwords are hashed, never stored in plain text. Ask which algorithm. The acceptable answers in 2026 are bcrypt, scrypt, or argon2. If anyone mentions MD5 or SHA-256 alone for passwords, that is a red flag.
• Multi-factor authentication is available at least for admin and high-value accounts. It does not have to be mandatory for every user on day one, but it should exist.
• Sessions expire and can be revoked. When a user logs out or you disable an account, access should end promptly, not hours later.
• Authorization is checked on the server, every time. A common bug is hiding a button in the UI but leaving the underlying API open. Ask: if someone changes the ID in the URL from their own to a stranger's, what stops them from seeing that stranger's data?

That last question exposes one of the most frequent real-world breaches. Make your team walk you through the answer concretely.

HTTPS everywhere

Every page, every API call, every asset should travel over HTTPS. Not just the login page.

• The site should automatically redirect plain HTTP to HTTPS.
• Certificates should renew automatically, usually through something like Let's Encrypt. Expired certificates take sites down and erode trust.
• Ask whether HSTS is enabled. It tells browsers to refuse insecure connections to your domain, which closes a subtle downgrade attack.

This is cheap to do correctly and embarrassing to get wrong, so there is no good reason to compromise here.

Input validation and output handling

Almost every classic web vulnerability comes down to the application trusting data it should not trust.

• SQL injection happens when user input is glued directly into a database query. The fix is parameterized queries or a well-used ORM. Ask your team to confirm no query is built by string concatenation.
• Cross-site scripting (XSS) happens when user-supplied content is rendered as code in someone else's browser. Modern frameworks like React escape output by default, but file uploads, rich text editors, and email templates are common gaps.
• File uploads deserve special attention. Validate type and size, store files outside the web root, and never execute what users upload.

A useful framing: the application should treat all incoming data as hostile until proven otherwise.

Secrets, dependencies, and the supply chain

Your code depends on hundreds of third-party packages, and your servers hold credentials that unlock everything.

• No secrets in the code repository. API keys, database passwords, and tokens belong in environment variables or a secrets manager, never in the source. Ask if anyone has ever committed a secret by accident, and what was done about it. Rotating it is the correct answer.
• Dependencies are scanned and updated. Tools like npm audit, Dependabot, or Snyk flag known vulnerabilities in libraries. Ask how often dependencies are reviewed. Once a quarter is a floor, not a ceiling.
• The principle of least privilege applies to infrastructure. The web server should not have admin rights to your cloud account. A leaked credential should unlock as little as possible.

The 2021 Log4j incident showed how a single library can expose millions of applications overnight. You cannot prevent every such event, but you can be in a position to patch within hours rather than weeks.

Backups, logging, and rate limiting

These are the things nobody appreciates until the day they are needed.

Backups

• Backups run automatically on a defined schedule.
• They are stored separately from the live system, so a compromise or accidental deletion does not take both.
• Most important: someone has actually restored from a backup recently. An untested backup is a guess, not a safety net.

Logging and monitoring

• The application records who did what and when, especially logins, permission changes, and administrative actions.
• Logs do not contain passwords, full card numbers, or other sensitive data.
• Someone or something is alerted when error rates spike or suspicious patterns appear. Logs nobody reads are only useful after the fact.

Rate limiting and abuse protection

• Login and password-reset endpoints limit attempts, so attackers cannot guess passwords millions of times.
• Public APIs cap how often a single client can call them, which also protects you from runaway bills and accidental denial of service.

How to use this checklist with your team

Do not hand this over as a pass-or-fail exam. Use it as a conversation. For each item, ask three things: is it done, how do we know, and what would it take to verify. A confident team will welcome the questions and may point out items specific to your domain, like payment compliance or health-data rules, that this general list does not cover.

Also accept that security is never finished. The right posture is regular review, fast patching, and a culture where reporting a mistake is safer than hiding it. A checklist gets you to a strong baseline. Discipline keeps you there.

Where Naazware fits in

At Naazware we build web, mobile, and desktop applications for clients around the world, and security is part of how we design from the first sprint rather than a box ticked at the end. We are happy to walk through this checklist against an application you already own, or to build your next product with these foundations in place from the start. If you would like a clear, jargon-free read on where your software stands, get in touch and we will be glad to help.