Web App Security Testing Checklist: 12 Checks Before You Launch

Most security incidents at small and mid-size companies don't need a clever hacker. They come from basic gaps: a missing permission check, an admin page anyone can open, or a library that hasn't been updated in two years.

This checklist covers the 12 checks we recommend before any web app or API goes live. It follows the same areas as the OWASP Top 10, the industry's standard list of common web security risks.

Why test before launch, not after

• It's cheaper: fixing a flaw before launch is a code change. Fixing it after a breach also means investigation, customer notices and lost trust.
• Launch is when you get noticed: automated bots start probing new websites and APIs within days of going live.
• Clients ask for it: enterprise customers, banks and auditors increasingly ask for a recent VAPT report before they sign.

The checklist

Login and sessions

• Limit login attempts: enforce strong passwords, and lock or slow down accounts after repeated failed logins.
• End sessions properly: sessions expire after inactivity, logout really ends the session, and tokens never appear in URLs.
• Secure password reset: reset links work only once, expire quickly and don't reveal whether an email is registered.

Access control

• Users can't see each other's data: change an order ID or user ID in the URL or API call and confirm you get an error, not someone else's data. This is one of the most common serious flaws in business apps.
• Roles are checked on the server: hiding the admin button is not enough. Every admin page and API must check the user's role on the server.

Input and data

• Validate every input on the server: test forms and API fields for SQL injection and cross-site scripting (XSS).
• Restrict file uploads: allow only the file types and sizes you need, and never let uploaded files run as code.
• Protect sensitive data: use HTTPS everywhere, encrypt sensitive data at rest, and keep passwords, card details and API keys out of logs.

APIs

• Lock down every endpoint: each API endpoint requires authentication, has rate limits, and returns only the fields the screen actually needs.

Configuration and components

• Harden the setup: turn off debug mode, remove default accounts, hide stack traces from error messages and set security headers.
• Update third-party libraries: run a dependency scan and update packages with known vulnerabilities.

Mobile apps (if you have one)

• Keep secrets off the device: no API keys in the app code, sensitive data stored encrypted, and all calls over HTTPS with proper certificate checks.

Vulnerability scan vs penetration test

A vulnerability scan is an automated tool that checks for known issues. It is fast and cheap, and can run on every build. A penetration test is a person thinking like an attacker. It finds flaws a tool can't, such as one customer being able to see another customer's orders.

You need both. Run scans continuously in your CI/CD pipeline, and run a manual penetration test before major releases.

Tools we use

For web apps and APIs, we use OWASP ZAP and Burp Suite, with Postman collections for API testing, plus dependency scanners for third-party code. Tools find candidates. Experienced testers decide which findings are real, how serious they are and how to fix them.

How often should you test?

• Before every major launch or redesign.
• At least once a year for business-critical apps.
• After big feature changes, especially to login, payments or permissions.
• Continuously, with automated scans in your build pipeline.

What a good security report looks like

A useful report ranks every finding by risk and shows evidence, the steps to reproduce it and a practical fix your developers can apply. It should be followed by a walkthrough with your team and a retest to confirm the fixes work. A long PDF of scanner output with no priorities is not a security test.

How to prepare for a security test

A little preparation makes the test faster and the results more useful. Before testing starts, have these ready:

• A clear scope: the URLs, apps and API endpoints to test, and anything that is off limits.
• Test accounts for every role: for example a normal user, a manager and an admin, so testers can check that each role sees only what it should.
• A staging environment that matches production as closely as possible, with realistic but non-sensitive test data.
• API documentation or a Postman collection, so no endpoint is missed.
• A named contact on your side who can answer questions and act quickly if something unexpected happens.

Agree up front how serious findings will be reported. A critical flaw should reach your team the same day, not wait for the final report.

How INNOVISCENT can help

Our security testing team runs VAPT for web apps, mobile apps and APIs. We sign an NDA before we start, test on staging where possible and agree testing windows for anything on production. You get a risk-ranked report, a walkthrough and a free retest of the fixes.

Frequently Asked Questions