Your team can demonstrate that a customer signs in and reaches a dashboard. That proves the happy path works. A security assessment asks a different set of questions: can the wrong person recover the account, can an old session remain useful, and can an authenticated user reach someone else’s records?
The short version
- Review the complete account lifecycle, including recovery and sign-out.
- Test identity and permission checks separately.
- Verify outcomes at the server, including requests the interface does not expose.
01 / Web application security
Start with the account, not the login screen
List every route into the same account: password sign-in, single sign-on, invitations, recovery links, trusted devices, and support-assisted changes. Include administrator and service accounts. Assign an owner to each route so an identity review does not stop at the most visible form.
OWASP recommends stronger verification around sensitive account changes and risk events, including recovery and suspicious activity. Its authentication guidance also covers MFA and throttling automated attempts. [1]
Our assessment question: What evidence of identity is required to change a password, replace a second factor, or update the recovery address? Walk through those changes with the teams that operate them. A strong sign-in method loses value if an easier recovery route grants the same access.
02 / Web application security
Treat recovery as a security feature
OWASP’s recovery guidance calls for reset tokens that are unpredictable, securely stored, time-limited, and usable once. It also recommends consistent responses for existing and nonexistent accounts to reduce account discovery. [2]
For your review, create an approved test account and record the expected lifecycle of a reset request. Check expiration and reuse, then examine what happens to existing sessions after the change. Review the help-desk process alongside the software: who can approve an exception, what evidence is recorded, and how is the legitimate account holder notified?
Keep the recovery journey understandable. Staff and customers should have a clear route to report an unexpected reset without sending passwords or live tokens through support messages.
03 / Web application security
Check what survives after sign-in
A browser session represents ongoing access. OWASP describes cookie protections such as Secure, HttpOnly, and SameSite, alongside session renewal, timeout, and invalidation. These controls serve different purposes; a cookie flag alone does not establish that the account lifecycle is secure. [3]
Define the behavior your product needs when someone signs out, loses a device, changes their password, or has their role removed. Then observe the server’s response to a previously issued session. Record any deliberate delay before access ends so the business can assess it.
Illustrative review: A departed contractor’s browser still displays cached project information. Determine separately whether the display is stale and whether the old session can retrieve fresh records. Those are different findings with different fixes.
04 / Web application security
Authentication does not settle authorization
Authentication establishes who is making a request. Authorization decides whether that identity may perform the requested action on a particular resource. OWASP recommends denying access by default and checking permissions on every request, including requests made outside the normal interface. [4]
Use a small matrix of approved test identities: two ordinary users in different organizations, an administrator, and a disabled user. Check viewing, editing, exporting, and deleting representative records. Include direct API requests and background jobs. Hiding a button is a presentation choice; the assessment needs evidence that the server enforces the intended boundary.
05 / Web application security
Build a review your team can repeat
Start with one important account journey and produce a compact evidence record:
- The identity, role, and account state used in the test.
- The action attempted and the permission it should require.
- The observed server result, with credentials removed from evidence.
- The finding’s business impact, owner, and remediation priority.
- A follow-up check that demonstrates the intended behavior after a fix.
Repeat the review when sign-in providers, recovery processes, or permission models change. A useful result gives product and engineering teams a precise boundary to maintain, rather than a general statement that the login looks secure.
Turn insight into action
Discuss the workflow, information, and controls you want to assess. We’ll help define a clear testing scope and practical next steps.
Plan a web application assessmentResearch & sources
Read the original guidance
Primary guidance checked on 6 November 2026. Examples and suggested review activities are Redteam Cybersec’s editorial synthesis. They do not describe a client engagement or establish the security of a particular system.
- OWASP — Authentication Cheat SheetRe-authentication, MFA, and protection against automated attempts.
- OWASP — Forgot Password Cheat SheetRecovery tokens and consistent account-recovery responses.
- OWASP — Session Management Cheat SheetSession cookies, lifecycle, and invalidation.
- OWASP — Authorization Cheat SheetDefault-deny access and request-level authorization.