Authentication & Authorization Testing

Teams conflate these and it costs them. An application can have flawless login and still leak every customer’s data, because a logged-in user can change an ID and read another account. The reverse happens too: tight authorization behind a login anyone can bypass. We test each independently, then together, so a strong control on one side cannot mask a broken one on the other.

You cannot test authorization with one login. We ask for at least two accounts per role: two ordinary users, an admin, and where relevant accounts in separate tenants. Then we systematically try to make one account do what only another should, which is the only way to prove access control actually holds.

We start by enumerating every authenticated function and every identity flow: login, registration, password reset, MFA enrolment, SSO, token refresh and API authentication. Each is a separate attack surface with its own failure modes, and missing one is how a bypass slips through to production.

We test whether the login itself can be defeated or worn down.

Login and brute force

We check rate limiting, lockout and whether error messages let an attacker enumerate valid usernames. A reset endpoint that says “no such account” for one email and “sent” for another is a user-enumeration oracle, and paired with weak rate limiting it turns credential stuffing into a numbers game the attacker wins.

Multi-factor authentication

MFA is only as strong as its weakest path. We test whether the second factor can be skipped by hitting a later endpoint directly, whether OTP verification is rate-limited, whether a six-digit code can be brute-forced, and whether the MFA reset flow quietly bypasses the factor it was meant to protect.

Password reset and recovery

Reset flows are a favourite target. We test for guessable or reusable tokens, tokens that never expire, host-header injection that sends the reset link to an attacker’s domain, and responses that leak whether a token was valid.

Once authentication is mapped, we attack what each account can reach.

Horizontal escalation and IDOR

We change identifiers in requests to reach other users’ records. Insecure direct object references are the most common access-control finding and, in multi-tenant applications, frequently the most serious, because one flaw exposes every customer.

Vertical escalation

We call privileged functions from unprivileged accounts. Where the app decides your role from a tamperable token or trusts a client-supplied flag, escalation to admin is often quick.

OAuth breaks in well-known ways and we test each. Loose redirect_uri validation that allows path traversal or an open redirect can send the authorization code to an attacker. A missing or unchecked state parameter opens login CSRF. We also test account-linking flows, where an unverified email can bind an attacker’s identity to a victim’s account.

Where SSO uses SAML, we test signature validation and XML parsing. Assertion handling that trusts an unsigned or wrapped assertion, or a parser differential between what is validated and what is read, lets an attacker forge an identity. These are subtle and firmly in manual-testing territory.

JWTs are everywhere and misused often. We test whether the server accepts the none algorithm, whether it is vulnerable to algorithm confusion where an RS256 token is re-signed as HS256 with the public key, whether the signature is checked at all, and whether tampering with claims like role or user ID changes what the server grants.

A short read for leadership: whether an outsider can get in, whether an insider can reach more than they should, and what either would mean for your customers and your compliance position.

Each finding carries the affected flow, a CVSS score, business impact, exact reproduction with request and response evidence, and a specific fix. Authentication and authorization findings are labelled distinctly, so your team fixes the right control in the right layer.

After you apply the fixes we re-test each finding at no charge, because a half-fixed auth bypass is still an auth bypass, and update the report to reflect what is genuinely closed.

Authentication and session management have their own detailed chapters in the OWASP Application Security Verification Standard, and access control maps to OWASP Top 10 A01. We test against these so your team gets a recognised checklist alongside the findings.

Access control is central to every one of these frameworks. The report and attestation letter are written to support ISO 27001 access-control controls, SOC 2, PCI DSS requirement 8 on identity, GDPR and DORA. Name your framework and we align the deliverables.

We check that session identifiers are long and unpredictable, that a new session is issued on login rather than the pre-login one being reused, and that an attacker cannot fix a known session on a victim. Predictable tokens and session fixation both lead to takeover without ever knowing a password.

We verify the Secure, HttpOnly and SameSite attributes on session cookies. An HttpOnly cookie survives an XSS that would otherwise steal it, and a sensible SameSite value shuts down a class of cross-site request attacks before they start.

A session that never expires, or one that stays valid on the server after the user clicks logout, undoes the whole point of logging out. We test idle and absolute timeouts, server-side invalidation on logout, and how the app handles the same account signed in from several places at once.