Identity control plane
Prove five boundaries, not one login screen
Each boundary has a different failure mode. Passing sign-in does not prove permission enforcement, safe recovery or administrator isolation.
Enrollment
Create and verify an identity without creating an account-enumeration oracle.
- Define
- Eligible users, verification, duplicate identities and consent
- Attack
- Automated signup, enumeration and unverified ownership
- Evidence
- Generic responses, rate controls and verified lifecycle tests
Authentication
Verify identity with an approved provider and explicit assurance level.
- Define
- Authenticators, MFA, sensitive accounts and fallback
- Attack
- Credential stuffing, spraying and inconsistent error timing
- Evidence
- Provider settings, negative tests and audit events
Session
Keep authenticated state bounded, revocable and protected in transit.
- Define
- Cookie attributes, duration, rotation and logout
- Attack
- Session fixation, theft and stale privilege
- Evidence
- Token lifecycle test across login, elevation and logout
Authorization
Enforce every object and action on the trusted side of the boundary.
- Define
- Roles, relationships, ownership and default deny
- Attack
- ID swapping, hidden endpoints and client-only role checks
- Evidence
- Cross-role and cross-object negative requests
Recovery and admin
Keep recovery from becoming the easiest route to privileged access.
- Define
- Reset, reauthentication, support override and break-glass
- Attack
- Reusable links, social engineering and shared admin
- Evidence
- Expiry, revocation and separately audited administrator path
Operating principle
Model permissions as business rules, then test denied requests
Identity features are often generated from the visible happy path: a form, a provider callback and a hidden dashboard. The real policy lives in which subject may perform which action on which object under which conditions.
Write that policy before implementing roles. Then test direct requests that violate one dimension at a time. A reliable denial is a product requirement, not a penetration-testing afterthought.
- Deny by default
- Check permission on every request
- Keep internal service identities out of public login
- Log failures without leaking sensitive detail
Applied example
Failure example: the hidden admin button
A generated dashboard hides the billing export unless the client session says admin. Calling the export endpoint directly with a normal account still returns the file.
- Authentication succeeded correctly
- The interface represented a role but did not enforce it
- The endpoint trusted client-controlled state
- A negative authorization test would have caught the defect
Plain answers
Questions to resolve before shipping
Is using an authentication provider enough?+
A provider can handle important identity mechanics, but your application still owns authorization, data access, lifecycle configuration and integration testing.
Should every application require MFA?+
Choose authentication assurance from risk, account privilege and user context. Privileged and high-consequence actions commonly need stronger protection.
Can VibeFootprint verify authorization?+
No. A public scan cannot use private roles or safely test protected actions. It can only point to visible context and separate public findings.