Start with what a security check can—and cannot—tell you
If you are asking how to check app security, begin by defining the claim you want the check to support. A security review can identify weaknesses in a particular version, environment and set of tested journeys. It cannot prove that an application is secure under every condition or predict every future vulnerability.
Use established references to organize the work. The OWASP Application Security Verification Standard provides testable requirements, while the OWASP Web Security Testing Guide describes testing techniques. The OWASP Top 10 is useful for awareness, but it is not a complete test plan. Record which standard and version you use so the scope remains reproducible.
1. Define the app, risks and boundaries
Create a compact inventory before opening a scanner. List the application URL, build or commit, environments, user roles, APIs, third-party services, sensitive data and consequential actions. Include less visible surfaces such as administration routes, webhooks, background jobs, file storage and password-reset flows.
Then write several plausible misuse cases. Could one customer access another customer’s records? Could a basic user reach an administrative function? Could an attacker automate account creation, reuse a reset link or trigger repeated purchases? This threat-led view helps distinguish important weaknesses from noisy configuration observations.
- Name the version and environment being tested.
- Identify trust boundaries and privileged roles.
- Mark actions that send, publish, delete, purchase or disclose data.
- Document exclusions and assumptions.
2. Establish safe testing conditions
Only test systems you own or are explicitly authorized to assess. Prefer a production-like staging environment for active tests, with representative configuration and disposable accounts. Production checks should normally remain passive unless the owner has approved the exact actions and potential effects.
Before testing, confirm backups, monitoring contacts, rate limits and a stop procedure. Do not use real personal, payment or confidential data when synthetic data will work. An aggressive scan can create records, send messages, lock accounts or degrade service, so tool defaults are not automatically safe.
3. Check the public security baseline
Inspect the app as an unauthenticated visitor. Confirm that HTTPS is enforced, the certificate is valid for the hostname and pages do not load active content over insecure connections. Review cookies for Secure, HttpOnly and appropriate SameSite settings. Examine caching rules where responses contain private data.
Security headers deserve review, but their presence is not proof of security. A Content Security Policy should match the app’s actual resource needs; an overly broad policy may add little protection. Similarly, restrictive cross-origin settings help only when server-side authorization is correct.
- Check redirects from HTTP to HTTPS.
- Look for exposed debug pages, source maps, backups and verbose errors.
- Confirm sensitive responses are not unintentionally cached.
- Review clickjacking, content-type and referrer protections in context.
4. Test authentication, sessions and access control
Identity and authorization failures often require manual testing because scanners cannot reliably understand who should be allowed to do what. Create at least two ordinary test accounts and, where authorized, accounts for each privileged role. Attempt the same legitimate journey while signed out, as another user and as a lower-privileged user.
Authorization must be enforced by the server, not merely by hidden buttons or client-side route guards. With permission, verify that changing an object identifier does not reveal or alter another account’s data. Stop if a test could affect a real user.
- Test registration, sign-in, sign-out, password reset and account recovery.
- Confirm reset links expire and cannot be reused after a successful reset.
- Check whether sessions are invalidated after password changes or explicit logout.
- Verify administrative and API operations reject insufficient privileges.
- Review defenses against automated guessing without launching disruptive traffic.
- If multifactor authentication exists, test recovery and bypass paths as carefully as enrollment.
5. Inspect inputs, APIs and file handling
Map what the browser sends using developer tools or an intercepting proxy in an authorized environment. Do not assume an endpoint is safe because the interface never exposes it directly. Check that the server validates data types, lengths, formats and allowed values, and that output is encoded for its destination.
Review APIs for authentication, object-level authorization, excessive data exposure and unsafe mass assignment. For uploads, verify file type, size, storage location, generated filenames and download behavior. Active injection or denial-of-service payloads should be limited to controlled environments with explicit approval.
- Check state-changing requests for cross-site request forgery defenses where relevant.
- Treat browser validation as usability support, not a security boundary.
- Confirm error responses do not disclose secrets, queries or internal paths.
- Test both accepted and rejected input, including boundary values.
6. Review source code and the software supply chain
If source is available, combine manual review with static analysis, dependency analysis and secret scanning. Search deployment files, history and build logs as well as current application code. A secret removed from the latest commit may still exist in history and should be rotated if it was exposed.
Dependency findings require context. Record the installed version, affected component, known vulnerability, exploit preconditions and whether vulnerable code is reachable. Also inspect lock files, update practices, build permissions and production configuration. Scanner severity alone should not determine priority.
- Look for hard-coded credentials and overly broad service permissions.
- Trace authorization checks around high-impact server operations.
- Review cryptographic use rather than inventing custom schemes.
- Separate development conveniences from production settings.
- Record tool versions and rule sets so results can be reproduced.
7. Follow data and consequential actions end to end
Trace sensitive data from collection through transmission, storage, logging, export and deletion. Check whether the app collects more than it needs, exposes data in URLs or analytics events, or writes credentials and tokens to logs. Encryption helps, but key access and operational permissions also matter.
Business-logic testing is equally important. Examine purchases, invitations, approvals, publishing, account deletion and external notifications. Test duplicate submission, stale pages, reordered steps and interrupted workflows with disposable data. Determine whether retries can repeat an effect and whether the app presents uncertain outcomes honestly rather than claiming success.