Threat Modeling Modern Applications - An Interview Guide

After recently completing a few interview loops for Security Engineer roles, one common requirement between different organizations is a round based on threat modeling or secure system design. There’s a good amount of confusion on discussion boards for how to prep for these interviews or how to approach them. I’ll share my approach and some tips I’ve found to be useful in clearing this style of interview.

Contrary to what your recruiter probably told you: OWASP top 10 isn’t enough prep material for these things

Always cover the basics

While it’s beneficial to touch on exotic and obscure vulnerabilities that might be relevant to the application you’re threat modeling, it’s more important to cover the basics. Interviewers are usually looking for a discussion around XSS/SQLi/CSRF.

Some interviewers treat these things like a checklist and you can cover every base but if you forgot to say we should use TLS for data-in-transit that might result in the interviewer assuming you would miss that in an actual design review.

Microservices Security Architecture

This is the part many candidates overlook, these days most companies are operating in a microservice model, the days of a 3-tier web application architecture are behind us.

You need to be able to discuss a Zero-Trust Security architecture, where each service has strong authentication/authorization between the other services it interacts with.

A network firewall should not be considered sufficient to protect a service from unauthorized access.

Deeply understand the topics you plan to discuss

It’s very common for a candidate to rapid fire list security buzzwords, but you should be ready to justify every piece of your strategy and more importantly know the trade-offs between different options.

If you say we should use OAuth for authorization that’s a good approach, but can you tell me why? Can you explain the potential risks associated with different OAuth flows? Can you explain common pitfalls in storing access tokens and validating them? If not, don’t try to BS your way around the follow-up questions.

Provide multiple solutions, discuss trade-offs and be realistic

For many security issues, there will be a “best” answer. For example we can mitigate most authentication issues if we force MFA, but in reality that’s a poor user experience and for most businesses, requiring it for every user is not a viable solution.

Instead you can offer a compromise and require MFA when a user’s IP address or device identifier changes.

You should also use defense-in-depth for your mitigation strategies. For a junior level interview it might be sufficient to mention “input validation + output sanitization” as a mitigation for XSS, but at a senior level you should be talking about how the actual libraries used to perform that filtering work as well as additional protections like CSP and HttpOnly session cookies.

Do your research and be resourceful

You should definitely be performing OSINT on both your interviewers (if you have their names) and the company itself. If you’re interviewing with a tech company there’s usually a blog they publish which will give you insight into their architecture, and more often than not some detailed posts on how they dealt with security issues in the past.

If you’re interviewing for an Appsec team that recently open-sourced a tool to manage internal CAs for mTLS between services, it’s in your best interest to spend some time learning how that works, and playing with the tool if possible.

Understand the format

Generally I’ve seen this type of interview framed in 3 different ways:

Diagram: You’re presented with an architectural diagram of an application and it’s components
Verbal: The prompt is a specific app/feature and you will just talk through threats/mitigations i.e. “Threat Model a chat app”
Secure System Design: Similar to a Software Engineer ‘System Design’ interview you will be given a prompt for an application and expected to choose how to architect it, with the focus being on security. Threats and mitigations are usually described as you go.

Think like an attacker

Even though AppSec roles aren’t necessarily focused on offensive security, it’s very common for an interviewer to ask this follow-up question to a threat you mention:

“How would an attacker exploit this?”

“What would be the impact if this were exploited?”

If you don’t know what an XSS payload looks like, or how a session cookie can be exfiltrated through XSS you will have a hard time landing a mid-level or senior role.

It’s completely fine if you’ve never encountered these issues in a previous job, there’s plenty of free labs online to practice this, hands-on. I would recommend Portswigger’s WebSec Academy.

Ask questions first, avoid making assumptions

This is a great way to figure out the issues your interviewer expects you to focus on. You can confirm if certain categories of threats are within scope or if the protections can be assumed to already be in place, just by asking.

Clarify your approach and prioritize the threats

Every interviewer has a different style; many of these rounds are open-ended and good interviewers will let you lead the discussion to show off the areas you’re strongest in. Other interviewers will have some arbitrary check-list of issues they expect you to focus on, it can be hard to know which one of these we’re dealing with so set some expectations up front.

Some questions to ask:

“My preferred approach would be to start at the beginning of the diagram and list each threat and it’s associated mitigation for each component of the diagram, does that work for you?”

Some interviewers are looking for a specific methodology like STRIDE to be used, so if that’s the case it’s better to follow that format. Alternatively if the interview is geared towards adversary emulation it might not be expected/desired for you to even discuss mitigations.

Example

Here’s an example that contains many components, this is by no means supposed to be a full threat model, interviews will be time-boxed so I’ll list the major threats that come to mind and a summarized mitigation list for each.

Single Page App

The SPA is used for browser based access to the web application, so this is a good time to think about the browser security model and the associated vulnerabilities

XSS

Use static HTML
- By avoiding dynamic HTML generation you can almost eliminate all XSS issues
Use a templating engine
- Make sure not to pass user-input into templates (SSTI)
Utilize standard libraries for HTML sanitization, avoid creating custom logic to perform sanitization
HttpOnly flag
- In the event that an XSS exists, a victim’s session ID cookie can’t be stolen via document.cookie
CSP Response Header
Avoid passing input to dangerous JavaScript sinks like eval, href, innerHTML, etc

CSRF

SameSite Cookie Attribute
- At the minimum use it in Lax mode, which provides great protection against CSRF without breaking application functionality
CSRF Tokens
- This should be a requirement, until all browsers support Same-Site cookies this is the only full protection against CSRF
Avoid using GET requests for state changing actions
Request password for sensitive actions (change pw, etc)

MiTM

Use TLS 1.2+ for HTTP requests and only enable the use of Ciphersuites which enable Perfect Forward Secrecy.
HSTS
- If possible use preload directive, set high max-age

CORS Issues

Modern applications with a SPA front-end rely on many asynchronous AJAX calls to different domains. It’s a cumbersome task to manually configure the appropriate CORS headers resulting in development teams setting overly permissive CORS policies.

If the request contains sensitive information, the origin should be properly specified in the Access-Control-Allow-Origin response header.

User Authentication

Credential Stuffing/Account Bruteforcing

Rate Limiting
- Per IP, user, service or any combination of those factors
Captcha
MFA
Password length/complexity requirements

Account Enumeration

Use generic failure messages
- On failed login attempts, user registration, password reset features

Weak Password Reset Feature

Use strong PRNG to generate unique links
Set short expiration on reset links
Map each reset link to the specific user who requested it

Session Management

Session Hijacking

Use short-lived session IDs
Use long and randomly generated session IDs
Set session ID as a cookie, so it can be used with HttpOnly and Secure flags, providing additional protection against XSS and MiTM attacks.

Mobile App

Data Exposure to Other Applications

Use the appropriate data sharing and storage APIs for each mobile OS.

Mobile developers must be aware of known and legitimate data sharing capabilities in each platform, such as the UI Pasteboard (iOS), SD Cards (Android, Windows Phone), temp directories, cache locations, log files etc

Smart Fridge (IoT)

Unauthorized Access

Ensure every device is provisioned with a unique set of credentials (don’t hardcode them)

Insecure Network Services

Restrict open ports to the necessary minimum
Only use secure protocols

APIs

Microservice based applications with multiple client-types and heterogenous services usually use a standardized communication method: REST. You can probably assume that is the case here and that most of the common issues will be relevant.

Broken Authentication

Ensure tokens are signed by a trusted issuer, with a strong algorithm.
Validate the sig and aud parameter of tokens

IDOR

Use deny by default for controller methods
At the minimum use role-based access controls
Centralized permission evaluators are a great way to ensure all services are compliant with proper authorization checks. Open Policy Agent
is another good approach provide this functionality

Mass Assignment

Allow-list non-sensitive fields
Block-list sensitive fields
Use Data Transfer Objects, there are per framework solutions to achieve this for most modern web application frameworks
Do not use client side filtering which can easily be bypassed

Security Misconfigurations

Disable unnecessary HTTP methods on API resources
Avoid displaying strack traces in responses

MySQL DB

SQLi

Parameterized Queries
Password Hashing
- In the event a SQL injection does occur the passwords will won’t be accessible

Unauthorized Access

Ensure only the necessary port is exposed
Use TLS for the DB connection
Disable user login if possible

Microservice Security

Service to Service Authentication

mTLS
JWT
Trust the Network

Service to Service Authorization

mTLS
JWT

Passing end user user context between services

Avoid using HTTP headers for this, if the calling service wants to spoof the header the recipient service has no way to verify the authenticity
Pass it through a signed JWT, either the service signs it with a key-pair issued from a trusted CA or gets a trusted STS to sign the JWT

Miscellaneous

Weak Encryption

Use standard cryptographic libraries (don’t roll your own)
Avoid weak encryption/hashing algorithms
- Use AES256-GCM for data-at-rest
- Use Unique IVs for each round of encryption
- For hashing passwords in a DB use a purpose built password hashing KDF such as bcrypt or scrypt

OS Vulnerabilities

Containerization
Golden Images

Supply Chain Attacks

Maintain a Software Bill of Materials (SBOM)
Use Software Composition Analysis tools (SCA)
Reduce the number of 3rd party dependencies your application uses

Secrets and Key Management

Don’t harcode secret values in source code
Fetch secrets from mounted volumes, through an orchestrator or environment variables
Use a KEK (Key Encryption Key) with a trusted vault service like KMS/CyberArk/Hashicorp Vault.
- Each time your application needs to encrypt data a new data key can be created without ever exposing the master key

Denial Of Service

WAF
Rate Limiting
Auto scaling groups per service
File upload size limits

Design Recommendations

For every interview I’ve done, it was fair game to suggest additional components to the application. This will usually be done as you list threats through the discussion, but to keep this post organized I’ll list them here:

OAuth + OpenID Connect

I’d recommend OAuth as it’s a standardized and vetted framework for authorizing requests, this will reduce the likelihood of security issues related to building our own auth logic for the application.

For the specific implementation, I would use Authorization Code flow with PKCE (Proof Key for Code Exchange). This is especially important for browser based web applications.

OpenID (an extension to OAuth) will allow users to authenticate with 3rd party services, which offloads the responsibility of storing their credentials.

Ensure access tokens are not stored in LocalStorage and sent as an Authorization header in the SPA. A session ID cookie should be used instead and exchanged for an access token internally.
Alternatively if the JWT can fit; it can be stored as a cookie.

Edge Authentication

To simplify the authentication of requests, and reduce the amount of potential design flaws all requests can be authenticated at the edge (API Gateway)

The API Gateway will validate the request with it’s associated access token or session ID and forward it to the service it’s destined for.

Auth Service

To handle all authentication/authorization. In this context it can also be referred to as an STS (Secure Token Service). The following tasks will be handled by this service: