Overview
Applications have various account states (unverified, active, locked, disabled, deleted), and flaws in how transitions and states are enforced can be valuable findings. This capstone lesson covers account-state testing and consolidates authentication testing.
Learning objectives
- Explain account states and their transitions.
- Identify account-state weaknesses to hunt for.
- Consolidate the authentication-testing module.
Core concept
Account states describe the lifecycle status of an account — for example, unverified (registered but email not confirmed), active, locked (after failed logins), suspended/disabled, or deleted. Applications enforce different access rules per state, and transitions between states (verification, lockout, disabling, deletion) must be handled correctly. Weaknesses arise when state is enforced inconsistently: e.g. an unverified account accessing features it shouldn't, a disabled/deleted account still able to authenticate or retain access, or state checks missing on some paths (like APIs). These are valuable, sometimes high-impact findings.
How it works
Using test accounts in various states, the researcher checks that access rules are correctly enforced per state and across all paths: Can an unverified account access restricted functionality (bypassing verification)? Does a disabled or deleted account lose access everywhere (including APIs and existing sessions), or can it still authenticate/act? Are locked accounts truly restricted? Inconsistent enforcement — a state check present on the web UI but missing on the API, or a deleted account whose session still works — is a flaw. The researcher tests these transitions safely with their own test accounts, documenting weaknesses with evidence and fixes.
Practical example
Testing an in-scope application, the researcher creates a test account, has it disabled, and checks whether it can still act — finding that while the web UI blocks it, the API still accepts its existing session (the disable wasn't enforced everywhere). This inconsistent state enforcement is a valid finding (a disabled account retaining access), documented with a fix (enforce account state on all paths and invalidate sessions on disable). Using their own test accounts across states, the researcher found a real authorization/state flaw responsibly.
Cybersecurity relevance
Account-state flaws — unverified accounts accessing restricted features, disabled/deleted accounts retaining access, inconsistent state enforcement across paths (esp. APIs) — are valuable bug bounty findings, often overlapping with authorization issues and sometimes high-impact. They are frequently missed because they require testing transitions and multiple states, not just a normal login. This consolidates authentication testing — login, reset, MFA, sessions, and account states — a comprehensive, safe (test-account-based, in-scope) assessment of how an application authenticates and manages accounts end to end. For defenders, findings drive consistent state enforcement across all paths.
Common mistakes
- Only testing normal active accounts, missing state-transition and multi-state flaws.
- Not checking whether disabled/deleted accounts lose access everywhere (incl. APIs and existing sessions).
- Overlooking unverified-account access to restricted functionality.
Key takeaways
- Account states (unverified, active, locked, disabled, deleted) have different access rules; flaws arise from inconsistent enforcement across states, transitions, and paths.
- Common findings: unverified accounts accessing restricted features, disabled/deleted accounts retaining access, and state checks missing on some paths (e.g. APIs).
- Test transitions with the researcher's own test accounts across states; this consolidates authentication testing (login, reset, MFA, sessions, account states) into a comprehensive, safe assessment.
Check your understanding
- Give an example of an account-state weakness and why it matters.
- Why is testing account-state transitions across all paths (including APIs) important?