Threat Modeling, Testing, and Secure Development

Introduction

Authentication and authorization failures are rarely caused by a single defective line of code. They usually arise from interactions among identity providers, browsers, APIs, databases, session stores, tokens, recovery mechanisms, administrative interfaces, and deployment practices. A login endpoint may be well implemented while an account-recovery endpoint silently bypasses multi-factor authentication. An API may correctly verify a token while trusting a client-supplied role. A system may use strong cryptography but remain vulnerable to session fixation or OAuth code interception.

This chapter presents a systematic approach to identifying and testing these weaknesses. It combines threat modeling, secure software development, security testing, and OWASP guidance. The emphasis is on identity flows: registration, login, authentication-factor enrollment, session creation, authorization checks, token exchange, password recovery, logout, and privileged administration.

Security testing must be performed only against systems for which the tester has explicit authorization. The objective is to discover and remediate weaknesses, not to obtain unauthorized access or expose personal data.

Learning Objectives

By the end of this chapter, you should be able to:

• model threats against authentication and authorization flows;
• distinguish authentication, authorization, session management, and accountability controls;
• identify broken authentication, broken access control, privilege escalation, injection, token theft, replay, session fixation, insecure recovery, and OAuth attacks;
• design security requirements and abuse cases before implementation;
• select appropriate static, dynamic, unit, integration, and penetration tests;
• interpret test evidence and prioritize remediation using risk;
• integrate identity security into a secure software development life cycle;
• evaluate limitations, ethical duties, privacy requirements, and operational consequences.

1. Identity Security as a System Property

Authentication answers the question “Who or what is requesting access?” Authorization answers “What is that authenticated subject allowed to do?” Session management maintains the relationship between requests and an authenticated subject. Auditing records relevant security events so that actions can be investigated and contested.

These functions are related but not interchangeable. A valid password does not authorize access to every object. A valid access token does not prove that the token holder is the human who originally authenticated. A logged event does not prevent a compromise; it supports detection and response.

A useful identity-flow model contains five elements:

1. Principal: a human user, service, device, or workload.
2. Credential or authenticator: password, passkey, one-time code, certificate, or delegated assertion.
3. Verifier: the component that validates the authenticator.
4. Session or token: evidence carried between requests.
5. Policy decision point: the component that determines whether an action is permitted.

The security of the whole flow is constrained by its weakest trust boundary. If a secure identity provider issues a token to an untrusted redirect URI, or if a secure API authorizes based on a modifiable browser field, the overall system remains insecure.

Important terminology

• Attack surface: the set of interfaces, components, identities, data, and processes that may be attacked.
• Trust boundary: a point where data or authority moves between components with different trust levels.
• Threat: a potential cause of harm.
• Vulnerability: a weakness that can be exploited.
• Exploit: a technique or input that takes advantage of a vulnerability.
• Risk: the combination of likelihood and impact. It is not a precise universal equation; organizations may use qualitative or quantitative methods.
• Security control: a preventive, detective, corrective, or compensating measure.

2. Threat Modeling Identity Flows

Threat modeling is a structured activity performed during design and revisited when the system changes. It is not merely a list of common vulnerabilities. A useful model describes assets, actors, entry points, trust boundaries, assumptions, threats, controls, and residual risk.

2.1 Scope and data-flow representation

Begin with a data-flow diagram or equivalent narrative. For a typical web application, the flow may include:

• browser or mobile client;
• reverse proxy and web application firewall;
• authentication service or identity provider;
• application API;
• session or token store;
• user and authorization databases;
• email, SMS, or push provider;
• administrative console;
• logging, monitoring, and incident-response systems.

Mark where credentials, authorization decisions, tokens, personal data, and recovery codes travel. Identify whether each channel uses appropriate transport protection and whether each receiver validates input independently.

A compact threat-modeling sequence is:

1. Define security objectives. Examples include account confidentiality, tenant isolation, integrity of role assignments, and resistance to impersonation.
2. Identify assets. Include credentials, sessions, refresh tokens, recovery links, personal data, payment information, and administrative functions.
3. Identify actors. Consider unauthenticated visitors, ordinary users, malicious insiders, compromised accounts, malicious applications, rogue administrators, and external attackers.
4. Map flows and boundaries. Document where authority is created, transformed, stored, and consumed.
5. Generate threats. Use STRIDE, abuse cases, attack trees, and domain-specific checklists.
6. Evaluate and prioritize. Consider exploitability, affected population, business impact, detectability, and regulatory consequences.
7. Select controls and tests. Every significant threat should have preventive and detective controls, an owner, and verification evidence.

2.2 STRIDE and identity-specific abuse cases

STRIDE classifies threats as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. It is useful, but identity systems require additional questions:

• Can an attacker authenticate as another principal?
• Can a user obtain another user’s object by changing an identifier?
• Can a low-privilege account invoke an administrative function?
• Can a token be used after logout, expiry, rotation, or password change?
• Can a recovery process become an alternative login mechanism?
• Can a relying party accept an assertion intended for another client?

An abuse case states an undesirable goal from the attacker’s perspective, such as: “An authenticated user reads another tenant’s invoice by changing the invoice identifier.” Acceptance criteria should then express the security property: “The server denies access unless the subject is authorized for that invoice in the current tenant.”

2.3 Threat prioritization

Risk matrices are useful communication tools but should not create false precision. A team may classify likelihood and impact as low, medium, or high, then give urgent attention to threats that combine high impact with plausible exploitability. Factors include the number of affected accounts, privilege gained, ease of automation, exposure of sensitive data, persistence, and ability to detect the attack.

Threats should be traced to requirements, implementation components, tests, and operational owners. A threat model that is not connected to work items and test evidence is documentation rather than an effective control.

3. Common Identity Threats and Their Tests

3.1 Broken authentication

Broken authentication includes weak credential handling, flawed login state transitions, insecure multi-factor authentication, account enumeration, and inadequate brute-force defenses. Typical causes include storing passwords reversibly, accepting predictable reset tokens, failing to invalidate sessions after a security event, or relying on client-side checks.

Password verification should use a dedicated password-hashing function with a unique salt and a work factor appropriate to current hardware. Passwords should not be encrypted for later decryption. Authentication errors should avoid revealing whether an account exists, while operational monitoring may still record useful internal details.

Tests should verify that:

• invalid credentials produce a consistent external response;
• rate limits and progressive defenses operate without creating an easy denial-of-service condition;
• successful login creates a fresh session identifier;
• changing a password invalidates or reviews existing sessions according to policy;
• multi-factor enrollment and recovery require appropriate reauthentication;
• disabled, locked, or deleted accounts cannot authenticate;
• authentication errors and administrative changes are logged without recording secrets.

3.2 Broken access control

Broken access control occurs when a server fails to enforce policy for a requested action. It includes insecure direct object references, missing function-level checks, client-controlled roles, cross-tenant data exposure, and failures to enforce ownership.

The central rule is that authorization must be decided server-side using trusted identity claims, resource attributes, action, and context. A hidden button is not an authorization control. A URL identifier is an input, not proof of ownership.

Tests should use at least two accounts with different privileges and, where relevant, two tenants. For each protected operation, test:

• same-user access;
• another user’s object;
• another tenant’s object;
• anonymous access;
• lower-privilege access to a higher-privilege function;
• altered HTTP method, content type, or parameter;
• access after role removal or account suspension.

The expected result must be defined by policy. A denial should not disclose sensitive object existence unless that disclosure is intentional.

3.3 Privilege escalation

Vertical escalation occurs when a subject gains a higher privilege, such as ordinary user to administrator. Horizontal escalation occurs when a subject accesses another subject’s resources at the same privilege level. Escalation can result from role confusion, mass assignment, insecure defaults, stale sessions, or authorization checks applied only to user-interface routes.

Effective defenses include centralized policy enforcement, least privilege, deny-by-default behavior, explicit allowlists for writable fields, and re-evaluation of privileges for sensitive operations. Tests should verify both direct and indirect paths, including APIs, background jobs, bulk operations, export functions, and administrative support tools.

3.4 Injection

Injection occurs when untrusted data changes the meaning of an interpreter’s command or query. Relevant interpreters include SQL, NoSQL, operating-system shells, template engines, LDAP, expression languages, and authorization-policy languages.

Parameterized queries, safe APIs, context-appropriate output encoding, schema validation, and avoidance of shell interpretation are preferable to ad hoc filtering. A validator that blocks one visible pattern is not a general injection defense.

Testing should combine code review, static analysis, safe test payloads in authorized environments, negative tests, and database or service monitoring. The test objective is not only to trigger an error but to establish that data remains data and cannot alter command structure. Error responses must not expose query text, credentials, or internal topology.

3.5 Token theft and replay

Tokens are bearer instruments when possession is sufficient for use. They may be stolen through malicious browser extensions, malware, logs, referer leakage, insecure storage, exposed URLs, compromised devices, or server-side breaches. Replay occurs when a captured credential or token is accepted again in an unintended context.

Controls include TLS, secure cookie attributes, short-lived access tokens, careful refresh-token rotation, audience and issuer validation, scope restriction, secure storage, redaction, and revocation or reuse detection where feasible. Tokens should not contain unnecessary personal data. JWT structure does not itself make a token trustworthy; signature, algorithm, issuer, audience, expiry, and policy must be validated.

Tests should check expiry, not-before handling, issuer and audience validation, signature verification, algorithm restrictions, scope enforcement, refresh-token reuse detection, logout behavior, and exposure through logs or URLs. A system must define what logout means: local session removal, token revocation, identity-provider logout, or some combination.

3.6 Session fixation and session lifecycle defects

Session fixation occurs when an attacker causes a victim to authenticate using a session identifier known to the attacker. The primary defense is to issue a new session identifier after authentication and after other privilege-changing events. Do not accept session identifiers from untrusted URLs or allow predictable identifiers.

Session tests should verify:

• identifier rotation after login and privilege elevation;
• secure, HttpOnly, and appropriately SameSite cookies;
• idle and absolute timeouts;
• invalidation after logout;
• protection against concurrent-session abuse where required;
• resistance to cross-site request forgery for state-changing browser actions.

A timeout is not a substitute for revocation. Sensitive systems may require reauthentication before changing a password, enrolling a factor, exporting data, or assigning roles.

3.7 Insecure account recovery

Recovery is often the weakest authentication path. Risks include predictable tokens, long-lived links, answers to public questions, email-only recovery for high-value accounts, token leakage in referrers, and failure to notify the user.

A secure recovery design uses high-entropy, single-use, time-limited tokens; avoids revealing account existence; binds the process to the intended account and action; invalidates prior recovery tokens when appropriate; and provides notifications and audit records. Recovery should not silently remove stronger factors without additional verification and risk assessment.

Tests should confirm single use, expiration, invalidation after password reset, resistance to account enumeration, safe handling of forwarded links, and appropriate session behavior after recovery. Test data must use controlled accounts and synthetic addresses.

3.8 OAuth and delegated authorization attacks

OAuth is an authorization framework, not a generic authentication protocol. OpenID Connect adds an identity layer. Confusing the two can lead to accepting an access token as an identity assertion without validating its intended audience or issuer.

Important threats include:

• Authorization-code interception: mitigated by PKCE, especially for public clients.
• Redirect-URI manipulation: mitigated by exact, pre-registered redirect matching rather than broad patterns.
• State or CSRF attacks: mitigated by binding the response to the initiating browser session.
• Mix-up attacks: mitigated by validating the selected issuer and response context.
• Token substitution: mitigated by validating issuer, audience, nonce where applicable, signature, and expiration.
• Open redirectors: prevented because they can facilitate code or token leakage.
• Overbroad scopes: reduced through least privilege and explicit consent.

Tests should verify that an authorization response cannot be attached to a different browser session, client, redirect URI, issuer, or transaction. They should also verify that access tokens are sent only to the intended resource server and that a relying party does not trust unvalidated claims supplied by the browser.

4. Security Testing Across the Secure SDLC

Security should be integrated into requirements, design, implementation, verification, release, and operations rather than postponed to a final penetration test.

Requirements and design

Define security properties as testable requirements. Examples include “only members of the same tenant may read a project,” “a recovery token is single-use,” and “a role change requires recent authentication.” Record assumptions and trust boundaries. Conduct threat modeling before implementation and after significant architectural changes.

Implementation

Use secure defaults, approved cryptographic libraries, parameterized data access, centralized authorization middleware, strict input validation, safe serialization, and dependency management. Code review should examine identity transitions and negative paths, not only the successful login path.

Verification methods

Automated tools are valuable but incomplete. A scanner may identify missing headers while failing to understand that an invoice endpoint lacks tenant authorization. Manual analysis and business-context testing remain essential.

Test design principles

A strong identity test suite includes positive, negative, boundary, state-transition, and regression tests. For every permitted action, define nearby forbidden actions. Test sequences, not only individual requests: register → verify email → enroll factor → login → change role → logout → reuse old token. Security defects frequently occur between states.

Use synthetic identities and isolated environments. Do not place real credentials or production tokens in test reports. Preserve evidence sufficient for reproducibility while minimizing personal data. Tests that alter roles, reset accounts, or send messages require cleanup and operational coordination.

5. Worked Application: Multi-Tenant Learning Platform

The following is an illustrative case. A university learning platform supports students, instructors, tenant administrators, and a central support team. It uses an external identity provider for login, an API with bearer access tokens, refresh tokens for long sessions, email recovery, and role-based access control.

Background and problem

A release introduces a new “download all grades” function. During review, the team notices that the endpoint accepts a course identifier and returns a file. The user interface displays the function only to instructors, but the API does not visibly check the instructor’s relationship to the course. The team also discovers that refresh tokens remain valid after a password change.

Analysis

Assets include grades, student identifiers, access tokens, refresh tokens, and role assignments. Relevant threats are horizontal escalation, vertical escalation, token replay, and privacy violations. Trust boundaries exist between the identity provider, browser, API, and grade database.

The threat model produces these abuse cases:

• a student requests an instructor-only export;
• an instructor requests a course belonging to another tenant;
• an attacker replays a refresh token after a password compromise;
• a support user accesses grades without a documented support purpose.

Approach and solution

The team moves authorization into a server-side policy service. The policy checks subject identity, current role, tenant, course membership, requested action, and resource state. The endpoint no longer trusts a role or tenant value supplied by the client. Database queries include tenant and course constraints, and the export job rechecks authorization when it executes rather than relying only on the request-time decision.

Refresh tokens are rotated on use and associated with a session family. Reuse detection invalidates the family and generates a security event. Password change triggers revocation of active refresh-token families according to the organization’s session policy. The API validates token issuer, audience, signature, expiry, and scope.

The test plan uses two tenants, two instructors, a student, and a support account. It verifies permitted exports, cross-tenant denial, student denial, altered identifiers, delayed background-job execution, refresh-token reuse, logout behavior, and audit records. The team also checks that exports are encrypted in temporary storage and deleted according to retention policy.

Outcome

The system prevents the direct escalation paths, detects refresh-token reuse, and creates auditable records. The case also reveals that authorization is not complete when a request is accepted: asynchronous jobs, cached responses, exports, and support workflows require equivalent controls.

Learning points

1. User-interface visibility is not authorization.
2. Authorization must be enforced at every execution boundary.
3. Token lifecycle policy must address compromise, not only expiration.
4. Tenant context is a security attribute and must be derived and checked server-side.
5. Security tests should use multiple identities and realistic state transitions.

6. Governance, Ethics, and Operational Concerns

Identity testing can expose highly sensitive information. Organizations should define written authorization, scope, testing windows, emergency contacts, evidence-handling rules, and disclosure procedures. Testers should follow least privilege, avoid unnecessary data collection, and stop when testing may affect real users or availability.

Privacy principles require purpose limitation, data minimization, retention control, access restrictions, and secure deletion. Logs should support detection without storing passwords, one-time codes, full tokens, or unnecessary personal information. Security monitoring must also avoid discriminatory assumptions: risk signals should be explainable, reviewed for bias, and subject to appropriate human oversight.

Regulatory obligations vary by jurisdiction and sector. Requirements may concern breach notification, access records, data protection, payment information, education records, or critical infrastructure. Compliance does not prove security, but failure to meet applicable obligations can increase harm and legal exposure.

Artificial intelligence can assist with log clustering, code review, test generation, and anomaly detection. It should not be trusted to make unsupervised authorization decisions or to receive production secrets and personal data. AI-generated tests and code require human review because models may omit business rules, reproduce insecure patterns, or generate plausible but incorrect security claims.

7. Contemporary Practices and Limitations

Modern identity programs increasingly use phishing-resistant passkeys, WebAuthn, adaptive risk assessment, workload identity, short-lived credentials, and software supply-chain controls. These technologies improve security when integrated correctly, but they introduce operational and recovery considerations. Passkeys require account-recovery planning; adaptive controls can lock out legitimate users; workload identities require disciplined key and permission management; and short-lived tokens do not eliminate theft during their valid period.

No single control is sufficient. Multi-factor authentication reduces password compromise but does not automatically solve authorization defects. Token encryption does not prevent misuse by an already authorized service. A web application firewall may block common payloads but cannot understand all business rules. Penetration testing provides valuable evidence but is time-bounded and cannot prove the absence of vulnerabilities.

A mature program therefore combines threat modeling, secure architecture, secure coding, automated tests, manual assessment, monitoring, incident response, and continuous improvement. Findings should be tracked to closure, validated after remediation, and used to update patterns, training, and requirements.

Best-Practice Checklist

• Model identity flows before implementation and after material changes.
• Enumerate assets, actors, trust boundaries, assumptions, and abuse cases.
• Enforce authorization on the server for every protected action and object.
• Rotate sessions after authentication and privilege changes.
• Validate token signature, issuer, audience, lifetime, and scope.
• Use secure, single-use recovery tokens and test the recovery path as rigorously as login.
• Apply PKCE, exact redirect matching, state protection, and appropriate OpenID Connect validation.
• Test multiple identities, tenants, roles, states, and request sequences.
• Use safe test data and written authorization.
• Treat logs, alerts, and incident response as parts of the security design.

Chapter Summary

Threat modeling makes identity risks visible before implementation by identifying assets, actors, flows, trust boundaries, abuse cases, controls, and residual risk. STRIDE is useful for systematic threat discovery, while identity-specific questions address impersonation, object access, privilege changes, token misuse, recovery, and delegated authorization.

Broken authentication, broken access control, privilege escalation, injection, token theft, replay, session fixation, insecure recovery, and OAuth attacks require different but connected controls. Server-side policy enforcement, secure session lifecycle management, careful token validation, single-use recovery mechanisms, parameterized interfaces, and least privilege are central defenses.

Security testing must span the secure SDLC. Unit, integration, static, dynamic, fuzz, manual, and penetration testing each reveal different classes of weakness. The strongest test suites examine negative cases and state transitions using multiple identities and tenants. Governance, privacy, ethical authorization, evidence handling, monitoring, and remediation are essential because identity testing affects real people and organizational authority.

Key Terms

Threat model: A structured representation of assets, actors, flows, threats, controls, and assumptions.

Trust boundary: A point where information or authority crosses between different trust levels.

Principal: A human, service, device, or workload that may request access.

Authenticator: Evidence used to establish control of an identity.

Authentication: Verification of a claimed identity.

Authorization: Determination of whether a subject may perform an action.

Session fixation: Attack in which a victim authenticates using a session identifier known to an attacker.

Bearer token: A token usable by whoever possesses it.

Replay: Reuse of captured authentication or authorization data.

Privilege escalation: Obtaining authority beyond the subject’s intended permissions.

Horizontal escalation: Accessing another subject’s resources at a similar privilege level.

Vertical escalation: Obtaining a higher privilege level.

Insecure direct object reference: Unauthorized access caused by trusting a client-controlled object identifier.

PKCE: Proof Key for Code Exchange, a mechanism that binds an OAuth authorization code to the initiating client transaction.

OpenID Connect: An identity layer built on OAuth 2.0.

Abuse case: A description of an undesired action an attacker may attempt.

Threat surface: The interfaces and components exposed to possible attack.

Refresh-token rotation: Issuing a new refresh token when one is used and detecting reuse of an old token.

Least privilege: Giving subjects only the authority necessary for their tasks.

Secure SDLC: Integration of security activities throughout software development and operation.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization and session management.
2. What is a trust boundary, and why is it important in an identity-flow diagram?
3. Explain why hiding an administrative button is not an authorization control.
4. State two defenses against session fixation.
5. Why is OAuth not, by itself, an authentication protocol?

Long Answer Questions

1. Describe a threat-modeling process for a web application that uses an external identity provider, browser sessions, and an API.
2. Explain how broken access control can produce both horizontal and vertical privilege escalation. Include appropriate tests.
3. Discuss the security requirements of an account-recovery workflow and explain how those requirements should be tested.
4. Compare static analysis, dynamic testing, integration testing, and penetration testing for identity security.
5. Explain the principal OAuth threats involving redirect URIs, authorization codes, state, issuer, audience, and scopes.

Analytical / Application Questions

1. An API checks a user’s role during login but never checks the role when processing a delayed export job. Analyze the threat and propose a design and test strategy.
2. A company reports that all access tokens are signed, yet an attacker can use a token issued for one service against another service. Identify the likely validation failure and recommend controls.
3. Design a small test matrix for a multi-tenant application containing an administrator, instructor, and student in two tenants. Specify the identities, actions, expected outcomes, and evidence to collect.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication determines what data a user may access, while authorization verifies a password.

B. Authentication verifies identity, while authorization determines permitted actions.

C. Authentication records events, while authorization encrypts sessions.

D. Authentication creates database backups, while authorization rotates keys.

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions.

Question 2

What is the primary defense against session fixation after successful login?

A. Display fewer navigation links

B. Increase the password length requirement

C. Issue a new session identifier

D. Store the session identifier in a URL

Correct Answer: C. Issue a new session identifier

Question 3

Which test most directly detects horizontal privilege escalation?

A. A user changes their own password

B. A student attempts to read another student’s record

C. An administrator reviews an audit log

D. A user logs out from a mobile device

Correct Answer: B. A student attempts to read another student’s record

Question 4

Why should an API not trust a client-supplied role field?

A. The field may be modified by the client

B. Roles can never be represented in tokens

C. Client fields are always encrypted

D. Role checks belong only in the user interface

Correct Answer: A. The field may be modified by the client

Question 5

Which property is most appropriate for a password-recovery token?

A. Predictable and reusable

B. Long-lived and shared among users

C. Single-use, time-limited, and high entropy

D. Stored in a browser URL indefinitely

Correct Answer: C. Single-use, time-limited, and high entropy

Question 6

What does PKCE primarily help protect in OAuth?

A. Database backups from ransomware

B. Authorization codes from interception and misuse

C. Password hashes from offline guessing

D. Audit logs from deletion

Correct Answer: B. Authorization codes from interception and misuse

Question 7

Which combination is most appropriate when validating a received access token?

A. Only its length and visual format

B. Only the username displayed by the browser

C. Signature, issuer, audience, lifetime, and applicable scope

D. Only whether the token is Base64 encoded

Correct Answer: C. Signature, issuer, audience, lifetime, and applicable scope

Question 8

Which activity best represents a security regression test?

A. Repeating a previously failed authorization test after remediation

B. Changing the application color scheme

C. Deleting all test accounts before testing

D. Testing only the successful login path

Correct Answer: A. Repeating a previously failed authorization test after remediation

Question 9

What is a key limitation of automated vulnerability scanners?

A. They cannot inspect any HTTP response

B. They may miss business-logic flaws such as tenant-isolation failures

C. They always modify production data

D. They replace the need for threat modeling

Correct Answer: B. They may miss business-logic flaws such as tenant-isolation failures

Question 10

In a secure SDLC, when should threat modeling normally occur?

A. Only after a production breach

B. Only after final deployment

C. During design and again when significant changes occur

D. Only when a penetration tester requests it

Correct Answer: C. During design and again when significant changes occur