The STRIDE Framework

STRIDE is a threat modelling framework developed at Microsoft and adopted by the OWASP Threat Modeling Process as its primary threat identification methodology. It categorises threats into six types, each corresponding to a violated security property. Working through these categories systematically ensures you consider the full attack surface.

S — Spoofing

Definition: An attacker impersonates a legitimate user, process, or component.

Spoofing attacks undermine authentication — the mechanism that proves you are who you claim to be.

Examples

• Stealing a session cookie and replaying it to impersonate a logged-in user
• Forging a JWT token to authenticate as a different user
• DNS hijacking to redirect traffic to a malicious server masquerading as a legitimate service
• Credential stuffing using leaked username/password pairs
• A rogue service on an internal network impersonating a trusted microservice

Questions to Ask

• How does each component verify the identity of callers?
• Can authentication tokens be stolen or forged?
• Is mutual TLS or API key authentication in use between services?
• Are credentials transmitted or stored securely?

Typical Mitigations

• Strong multi-factor authentication (MFA)
• Short-lived tokens with proper validation
• Mutual TLS between services
• Certificate pinning
• Anomaly detection on login attempts

T — Tampering

Definition: An attacker modifies data or code without authorisation.

Tampering attacks undermine integrity — the assurance that data has not been altered.

Examples

• SQL injection modifying records in a database
• Parameter tampering in HTTP requests (e.g. changing amount=100 to amount=1)
• A man-in-the-middle attack modifying messages in transit
• Malicious code injection into a build pipeline (supply chain attack)
• An authorised user editing another user’s records (IDOR)

Questions to Ask

• Can users modify data they shouldn’t have access to?
• Is data in transit protected against modification?
• Are inputs validated before being used in queries or commands?
• Can the integrity of code artefacts (binaries, scripts) be verified?

Typical Mitigations

• Input validation and output encoding
• Parameterised queries and prepared statements
• Digital signatures for data integrity verification
• Integrity checks on deployed artefacts (e.g. SLSA, code signing)
• Encrypted transport (TLS) between all components

R — Repudiation

Definition: An attacker performs an action and denies having done so, because there is no audit trail.

Repudiation attacks undermine non-repudiation — the ability to prove that an action occurred and who performed it.

Examples

• A user performs a financial transaction and later claims they did not
• An administrator deletes records and there is no log of the action
• A service performs an action on behalf of a user with no cryptographic proof
• Log files are modified or deleted to cover an attacker’s tracks

Questions to Ask

• Are all sensitive actions (login, data modification, privilege use) logged?
• Are logs tamper-evident and stored separately from the system being logged?
• Can users deny having performed actions that they actually performed?
• Is there a legal/compliance requirement for non-repudiation?

Typical Mitigations

• Comprehensive audit logging with immutable log storage
• Digital signatures on sensitive transactions
• Centralised log management (SIEM)
• Log integrity protection (append-only storage, log signing)
• Timestamps from a trusted source (NTP with authentication)

I — Information Disclosure

Definition: Sensitive data is exposed to parties who are not authorised to see it.

Information disclosure attacks undermine confidentiality — the assurance that data is only accessible to those who should see it.

Examples

• Verbose error messages exposing stack traces, database queries, or file paths
• An API returning more data than the client needs (over-fetching)
• Unencrypted sensitive data stored at rest
• PII exposed in URLs, log files, or analytics events
• Unauthenticated endpoints returning sensitive information
• TLS downgrade attacks exposing data in transit

Questions to Ask

• What sensitive data does the system handle? Where is it stored and transmitted?
• Are error messages safe to show to end users?
• Is all sensitive data encrypted at rest and in transit?
• Do API responses contain more data than the caller needs?
• Are secrets (API keys, passwords) committed to source control or stored in logs?

Typical Mitigations

• Encrypt sensitive data at rest (AES-256) and in transit (TLS 1.2+)
• Generic error messages for end users; detailed errors only in internal logs
• Response filtering to return only necessary fields
• Secret management (HashiCorp Vault, AWS Secrets Manager, etc.)
• Data minimisation — collect and store only what you need
• Regular scanning for secrets in code and logs

D — Denial of Service

Definition: An attacker degrades or disrupts a system’s availability.

DoS attacks undermine availability — the assurance that authorised users can access the system when they need it.

Examples

• Flooding a login endpoint with requests to exhaust compute or lock out users
• Uploading excessively large files to exhaust storage
• A poorly-optimised query triggered by user input that locks the database
• A resource exhaustion attack that consumes all available memory
• Malformed input that causes an unhandled exception and crashes the service

Questions to Ask

• Are there limits on request rate, file size, query complexity, and resource use?
• Can a single user exhaust shared resources?
• What is the blast radius if a component becomes unavailable?
• Are there retry storms or cascading failure risks?

Typical Mitigations

• Rate limiting and throttling at the API gateway and application layers
• Input size limits
• Circuit breakers for downstream dependencies
• Auto-scaling and redundancy (HA architecture)
• DDoS protection (Cloudflare, AWS Shield, etc.)
• Resource quotas and timeouts on all external calls

E — Elevation of Privilege

Definition: An attacker gains capabilities or access beyond what they are authorised to have.

Privilege escalation attacks undermine authorisation — the rules about what authenticated users are permitted to do.

Examples

• An authenticated user accessing another user’s records via IDOR (Insecure Direct Object Reference)
• A low-privilege user accessing an admin-only endpoint because authorisation is not enforced
• A container process escaping to the host via a kernel exploit
• Mass assignment allowing a user to set their own role to admin
• A service account with overly broad permissions being compromised

Questions to Ask

• Is authorisation enforced on every sensitive endpoint, not just the UI?
• Do users have the minimum permissions needed (principle of least privilege)?
• Are service accounts scoped to the minimum necessary permissions?
• Can a non-admin user access or modify admin functionality?

Typical Mitigations

• Enforce authorisation checks server-side on every request
• Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC)
• Principle of least privilege for all users and service accounts
• Allowlist-based authorisation rather than blocklist
• Regular access reviews and privilege audits

Applying STRIDE

For each component and data flow in your system, work through the relevant STRIDE categories and ask: “How could an attacker exploit this?”

Not every category applies to every element. A data store, for instance, is most susceptible to tampering, information disclosure, and DoS. An authentication endpoint is most at risk from spoofing.

Use the threat modelling tool to record each identified threat, score its risk, and define appropriate mitigations.