Web App Security Checklist: Top OWASP Risks to Test in Your Next Penetration Test

Most web apps don’t get hacked because “encryption is broken.” They get hacked because a few OWASP-style mistakes line up: one weak input check, one bad permission rule, one log that never gets written, and suddenly an attacker has a way in.

In this guide, I share a Web App Security Checklist built for real penetration tests. You’ll see the top OWASP risks to test, what evidence to collect, and the exact checks I run so your findings point to business impact (not just a scan report).

Featured snippet answer: Your best next step is to test authorization first (OWASP Broken Access Control), then move through authentication flaws, input handling (injection), session safety, and upload/file risks. Run these in a tight, evidence-first order so you don’t waste days on low-value issues.

OWASP risks in a penetration test: the order that saves time

Here’s the practical truth: you don’t test everything equally. In my experience, spending 1–2 hours confirming high-impact flaws beats spending a full day on “nice to have” issues.

For a Web App Security Checklist, I use this order because it finds the fastest path to real access:

1. Broken Access Control (can you read/change other users’ data?)
2. Authentication failures (can you take over accounts or bypass login?)
3. Injection (can you run commands or steal data through inputs?)
4. Insecure design/session issues (is session handling weak?)
5. Security misconfigurations (are headers, CORS, and secrets exposed?)
6. File upload / unsafe content (can you store a payload and get it executed?)

OWASP is not a “map to the treasure.” It’s a list of common ways apps fail. You still need to validate each risk with proof you can explain to a developer.

Broken Access Control (OWASP A01): test authorization, not just login

Broken Access Control is the top OWASP risk for a reason: it turns “a normal user account” into “a data viewer for everyone.” Authorization is the rules that decide who can do what.

Authorization checks are often missing in APIs and background endpoints. The UI might hide buttons, but the API still answers requests if you know the right IDs.

Web app security checklist step: IDOR and role bypass tests

This is the fastest way I confirm Broken Access Control. You look for access to other users’ records by changing IDs and parameters.

• Create two test users: userA and userB.
• As userA, capture requests for actions like viewing a profile, fetching orders, updating settings, or reading invoices.
• As userB, repeat the same request but swap the record IDs (like /api/orders/12345).
• Also try changing hidden parameters (like accountId, tenantId, workspaceId).

What you record: request URL, method, status code, response body difference, and the exact field that leaked. A simple screenshot + curl snippet is often enough for dev teams to reproduce.

Common mistake people make

Most people only test “view” endpoints. I also test actions that change data: update shipping address, change email, refund an order, download private documents, and export reports.

Read access is bad. Write access is worse. The impact jumps fast when you can modify another user’s account.

How to test multi-tenant apps without guessing

If your app is multi-tenant, you need to verify tenant boundaries. Many bugs look like “tenantId is trusted from the client.”

• Login as userA in tenant1, then change tenantId in requests to tenant2.
• Try the same call using a different subdomain (like tenant2.example.com) if the app uses host-based routing.
• Check if the app returns data from the wrong tenant with a 200 response.

In one 2025 engagement, the UI showed tenant filters correctly, but an export API ignored tenantId. The result was that a single click let a user download a full tenant report.

Authentication and session risks (OWASP A02): prove account takeover or bypass

Authentication problems can mean account takeovers, weak password resets, or login bypasses. In 2026, the boring issues still show up: weak MFA checks, broken reset flows, and sessions that don’t expire.

Authentication is “who you are.” Session handling is “how the site remembers you.” If either is weak, you get access.

Web app security checklist step: test password reset like an attacker

Password reset flows are where I find the most missed edge cases. The goal is not to “try random inputs.” The goal is to find flow breaks.

• Request a reset for a real user email and note the response.
• Check if the app reveals whether the email exists.
• Use an old reset token after it should be expired (watch for long token lifetimes).
• Try using one valid token to reset a different account.
• Try reusing a token multiple times and see if it’s invalidated after use.

Evidence tip: capture the token handling behavior (even if you can’t read the token itself) via response codes and error pages. Developers can confirm token validation logic.

Session checklist: cookies, rotation, and “remember me”

I always inspect cookies with DevTools or a proxy. You want to confirm these flags and behaviors:

• HttpOnly is set (so JavaScript can’t read the cookie).
• Secure is set (so it only sends over HTTPS).
• SameSite is set (helps prevent some cross-site attacks).
• Session IDs rotate after login and after privilege changes.
• Logout actually invalidates sessions (not just “delete on the client”).

Then I test session timeout. If “idle timeout” is supposed to be 30 minutes, I check what happens after 45 minutes. I’ve seen apps that never end sessions on the server.

What about MFA?

MFA is great, but it’s only useful if the app enforces it consistently. I test:

• Does adding/changing email require MFA?
• Do “high risk” actions re-check MFA?
• Can an attacker bypass MFA on certain endpoints (like API calls made directly)?

This is where the Web App Security Checklist changes from “best practice” to “real test plan.” You’re not checking MFA exists—you’re checking it’s enforced in every path that matters.

Injection (OWASP A03): find data theft paths, not only “proof of concept”

Injection is when the app treats user input like code or commands. In plain terms: the app should treat input as text, not instructions.

Injection includes SQL injection, command injection, LDAP injection, and template injection. You don’t need every type—focus on what fits the app.

Web app security checklist step: map inputs to sinks

The fastest way I test injection is by mapping “input” to “sink.” A sink is where dangerous data ends up.

• Inputs: URL params, form fields, JSON body fields, headers like User-Agent, and file names.
• Sinks: database queries, command builders, template rendering, search indexing, XML parsing, and report generators.

In practical terms, you look for high-value endpoints: login search, admin search, order lookup, account update, and any “report/export” feature.

SQL injection checks that produce real value

Most scanners say “SQL injection likely.” Dev teams want more.

To make findings actionable, try to prove one of these outcomes:

• Read data from another table or row.
• Bypass authentication query logic.
• Write data (less common, but high impact).

Tools I often use in 2026 tests include Burp Suite (with an intercepting workflow), sqlmap for targeted testing, and OWASP ZAP for coverage. I still validate manually, because automated results can be noisy.

Template injection and “who renders what”

Template injection is a quiet risk in apps with dynamic email templates, dashboard widgets, or CMS previews. If user input gets rendered by a server-side template engine, attackers may get more than text.

Check features like:

• Markdown or rich-text fields
• Preview pages
• Custom profile fields shown in emails
• Admin “custom template” screens

If you find a template injection, the key proof is whether an attacker can access secrets or internal metadata—not just whether a payload shows a harmless string.

Insecure design and vulnerable business logic (OWASP A04): test workflows like a customer

Insecure design is about how the app works, not just how it parses input. Business logic flaws happen when the app trusts steps, counters, or permissions in the wrong order.

This is why I like to test “end-to-end flows.” You’re looking for actions that cost money, change accounts, or reveal data.

Web app security checklist step: look for broken workflow rules

Here are examples that keep showing up:

• Refunds can be issued twice because the app doesn’t mark the order state correctly.
• Coupons can be applied repeatedly because the “used” flag is not checked server-side.
• Free trial tokens can be reissued because the “trial used” check depends on a client value.
• Role changes happen without checking the user’s current privilege level.

I write down the expected states like a flowchart. Then I test requests out of order: cancel before pay, pay before confirm, confirm after expiry, and so on.

Replay and concurrency checks

Many logic bugs show up under quick repeated actions. Try:

• Submitting the same form twice quickly (double purchase)
• Triggering the same “generate report” action multiple times
• Testing “idempotency” on endpoints that should be safe to repeat

Evidence matters here. Capture timestamps and show that the app processes the same request twice when it should reject the second one.

Security misconfiguration (OWASP A05/A06): headers, CORS, debug pages, and secrets

Misconfiguration is the OWASP category that makes you feel lucky—until you find a real secret. It includes missing security headers, verbose error messages, exposed admin panels, and bad CORS settings.

As of 2026, most teams still miss the basics because they depend on framework defaults. Frameworks help, but they don’t fix your deployment settings.

Web app security checklist step: test security headers and error handling

Don’t just scan for headers. Confirm behavior.

• Try a request that triggers an error and check if stack traces reveal file paths.
• Check headers like Content-Security-Policy, X-Frame-Options (or frame-ancestors in CSP), and Strict-Transport-Security.
• Confirm cookies set correct flags as described earlier.

If you find a misconfigured CSP, you can often turn it into a practical XSS risk or clickjacking risk. That’s when a “minor config issue” becomes a real finding.

CORS checklist: prove whether cross-site requests are allowed

CORS (Cross-Origin Resource Sharing) is how browsers decide whether one site can call another. Misconfigured CORS can let an attacker read responses from a victim’s browser session.

• Check the Access-Control-Allow-Origin value. If it’s * with credentials, that’s a red flag.
• Check if the app reflects an Origin header without validation.
• Confirm if sensitive endpoints set correct CORS rules.

This test pairs well with authorization testing. If CORS allows reads and authorization fails, the impact can be huge.

Debug endpoints and exposed files

I check for:

• Debug routes (e.g., /debug, /actuator, /__debug)
• Source map exposure (common in JavaScript apps)
• Backups and old files (like config.yml.bak)
• Swagger/OpenAPI docs that leak internal endpoints

If you confirm an exposed file contains secrets or internal keys, mention the exact lines and how they map to real systems (AWS keys, API tokens, signing secrets, etc.).

Insecure deserialization, SSRF, and unsafe data handling (OWASP risks beyond the top 5)

Some OWASP risks don’t show up every time, but when they do, they can be game over. I include them in the checklist because web apps often have “hidden” features like webhooks, fetch-from-URL, and session caching.

Insecure deserialization refers to when an app converts data back into objects without checking it safely. SSRF is when the server fetches a URL provided by the attacker.

Web app security checklist step: SSRF via “fetch URL” features

Look for features where users can supply a URL:

• Image downloads and “import from URL”
• Webhook callbacks
• Link previews
• Report fetching from remote URLs

Then test the URL handling:

• Try local IPs like 127.0.0.1 and link-local addresses like 169.254.169.254 (cloud metadata is often a target).
• Try DNS names if the app resolves them (some blocks only IP-based filters).
• Try different URL schemes if it accepts them (like http vs https).

I’m direct about this: even if you can’t confirm full impact, SSRF against internal services is still a high-risk finding because it changes the attacker’s network reach.

Insecure deserialization checks (what to look for)

You usually can’t guess deserialization without seeing language/framework clues. Still, you can test patterns:

• Endpoints that accept “serialized” blobs in JSON (base64 strings)
• Cookies or tokens that look like encoded objects
• Session stores that accept user-controlled data

If you find signs, you should coordinate with the team because safe proof often requires environment knowledge. This is a case where a good report explains the likely root cause clearly.

File upload and path traversal (OWASP A09-like risks): test uploads end-to-end

File upload bugs are popular because they’re easy to demonstrate—and often easy to fix once developers understand the real path.

Upload risk isn’t only about file type checks. It’s about where the file is stored, how it’s served, and whether it can be executed.

Web app security checklist step: bypass file type checks safely

Follow a safe workflow in your test plan:

1. Upload allowed file types first (like .png or .pdf) and confirm how the app stores them.
2. Try changing the extension only, then changing the MIME type, then changing both.
3. Try polyglot files (files that look like two formats at once) only if you have safe lab setup and proper authorization.
4. Request the uploaded file and check the response headers and content.

Evidence matters: the upload response (including file URL), the response headers when retrieving the file, and whether the server treats it as a download or as executable content.

Path traversal basics that still work

Path traversal is when user input gets used to build file paths on the server. If the app uses file names from the request to read files, you test for reading other files.

• Look for endpoints like /download?file=..., /image?name=..., /export/{name}.
• Test with path patterns like ../ and URL-encoded variants.
• Confirm whether the server blocks access, or returns different error messages.

If you find traversal that reads sensitive files, report the exact file paths and the kind of data exposed. This is the kind of finding that leaders understand instantly.

People also ask: quick answers security teams ask during planning

What should be included in a web app penetration test checklist?

A good web app penetration test checklist includes authorization tests, authentication and session checks, input validation and injection tests, workflow testing (business logic), and security misconfiguration checks like headers and CORS. You also want file upload and SSRF checks because they often lead to real code execution or internal access.

If you’re using OWASP as the backbone, map each OWASP risk to at least one concrete test in your plan. “We tested injection” isn’t enough. “We tested the search endpoint by sending payload X and got data from table Y” is enough.

How do I prioritize OWASP risks for my next test?

Prioritize by impact and reach. Start with Broken Access Control and authentication/session issues, then injection, then misconfiguration and upload/SSRF. If the app handles money, prioritize business logic flaws like refunds, coupons, and id changes.

Also prioritize what’s exposed. Admin-only features that aren’t reachable from the internet can still matter, but they usually get lower priority than public APIs that accept user-controlled IDs.

Do automated scanners catch OWASP risks reliably?

They catch patterns, not truth. Automated tools are good at finding obvious mistakes fast, like missing security headers or reflected input problems. But they often miss real authorization bugs and workflow logic issues.

In practice, I treat scanners as a “coverage helper,” not as the final proof. Your report should include manual validation with clear steps to reproduce.

What tools should I use for the OWASP Web App Security Checklist?

I use a mix, because each tool has a blind spot. Common choices include:

• Burp Suite: intercepting traffic, modifying requests, and manual verification.
• OWASP ZAP: quick coverage and baseline scanning.
• sqlmap: targeted SQL injection testing when authorized.
• Browser DevTools: cookie flags, redirects, and front-end behavior clues.

If your team uses a specific tool (like Nessus, Acunetix, or Invicti), that’s fine. The checklist matters more than the scanner brand.

A practical Web App Security Checklist you can reuse (with evidence targets)

This checklist is how I structure my work when I want solid results in a 5–10 day web app penetration test. Adjust based on scope, but keep the evidence targets.

Rule: every finding must answer “What did the attacker do?” and “What data or action changed?”

Day 1–2: authorization, auth, and session

• Map user roles and permissions. Confirm what each role should access.
• Test Broken Access Control using ID changes (IDOR) and role bypass calls.
• Validate session cookie flags: HttpOnly, Secure, SameSite.
• Test session expiry: idle timeout and absolute timeout.
• Test logout invalidation and session rotation after login.
• Test password reset and MFA enforcement for “high risk” actions.

Evidence to capture: request/response pairs, status codes, and the exact leaked or changed fields.

Day 3–4: injection and input handling

• Identify input points: query params, JSON fields, headers, and filenames.
• Map each input to where it goes (database query, template render, command builder).
• Test for SQL injection on search and account-related endpoints.
• Test for command injection in any “run job” or “import/process” flows.
• Check template rendering issues in previews, rich text, and email bodies.

Evidence to capture: show data access or logic bypass, not just error messages.

Day 5: business logic and workflow

• Create flow charts for checkout, refund, coupon, and account changes.
• Test requests out of order and repeat actions quickly.
• Check idempotency for endpoints that should ignore duplicates.
• Verify rate limits and anti-automation on sensitive endpoints (login, reset, export).

Evidence to capture: show the state transition (what changed on the server after the requests).

Day 6–7: misconfiguration, upload, SSRF

• Check security headers and how the app responds to errors.
• Verify CORS behavior for sensitive endpoints.
• Search for debug routes, hidden files, and leaked docs.
• Test file uploads: type checks, storage location, and response headers.
• Test downloads for path traversal and “unsafe direct object references.”
• Test SSRF using any “fetch URL” features.

Evidence to capture: URLs, headers, and whether the app executes/stores/reads the dangerous content.

Quick comparison: what to focus on for different web app types

Not all apps need the same depth. Here’s a fast comparison I use to set expectations with clients.

My opinion: your report should be written like a fix guide

I’ve reviewed too many pentest reports that read like a list of tool outputs. That doesn’t help the team. Developers need exact steps and exact code areas to check.

My rule for a strong Web App Security Checklist report is simple:

• Include the request and response details.
• State the expected rule (what the app should do).
• State what the app did instead (what actually happened).
• Point out the likely root cause in plain language.
• Give a safe remediation path (what to change and what to test after).

One “original” angle I push with teams: fix the first flaw that stops the attacker’s path. If Broken Access Control is real, many other findings become less urgent because attackers can already reach data.

Internal links for follow-up reading

If you want more practical content you can reuse during your next assessment, these posts fit naturally with this Web App Security Checklist:

• OWASP Top 10 practical testing steps (with sample payload workflow)
• Web API authorization guide: how to test tenant and role boundaries
• Session security best practices for 2026 (cookies, rotation, and timeouts)

Conclusion: test the path to impact, then document it so teams can fix it

Your next penetration test should not feel like a scavenger hunt. Use this Web App Security Checklist to test the OWASP risks that actually change outcomes: broken authorization, weak sessions, injection in key endpoints, business logic that breaks state rules, and risky upload/SSRF paths.

When you find issues, collect evidence that shows a clear attacker action and a clear data or state change. If your report reads like a “how to reproduce and fix” guide, you’ll see faster patching—and fewer repeat findings next quarter.