Making Sense of Threat Modeling with STRIDE


It is no mystery that information security has become more important than ever. Check the news and it seems that there is another big attack happening every day. Take for example these recent headlines.

US Warns of ‘DeltaCharlie’ - A North Korean DDoS Botnet

Dangerous Malware Discovered that Can Take Down Electric Power Grids

Warning! Hackers Started Using SambaCry Flaw to Hack Linux Systems

The number of attacks happening on a daily basis is staggering. This leads to the question, how can we as developers better secure our cloud services? Assembling a comprehensive security strategy can feel daunting. There are new 0-days appearing all the time. How do we begin to determine the who, what, when, where, and how of a potential attack? What we need is an organized approach to designing our systems based on our individual needs. This is where STRIDE comes in.

STRIDE is a methodical approach to identifying our application's assets and the most likely threats to them. What assets are we speaking of exactly? This would be anything that is stored in a database (especially user and financial data), CPU power, and files located in a file system. Once you have taken the time to evaluate your assets, you can then begin to assess the real threats that matter most to your infrastructure.

The way to evaluate these threats is by using the STRIDE acronym. STRIDE stands for spoofing, tampering, repudiation, information disclosure, and escalation of privileges. Each of the threats is specific to security properties that every application must maintain as shown below.

Spoofing - Authentication

Tampering - Integrity

Repudiation - Non-Repudiation

Information Disclosure - Confidentiality

Denial of Service - Availability

Escalation of Privileges - Authorization

Understandably, this is a lot to unpack and to better understand this, we will evaluate each security property to grasp the threats specific to them.


We all have experience with this one. Authentication is how we verify if users are who they claim to be. We do this through various means from basic Username/Password to more complex systems such as OAuth2 and SAML. Unfortunately, there is a wide range of threats for attacking an app's authentication scheme. Man-in-the-middle attacks, CSRF, and brute-force password attacks are all viable schemes. However, there are fundamental things we can do to better mitigate these attacks. This would include using HTTPS, enforcing password length and complexity, ban common password topologies (no more 123456 and password being accepted), and require re-authentication when users are conducting especially sensitive actions such as password changes. For a more comprehensive review of authentication best practices, please read the OWasp Authentication Cheatsheet.


Maintaining the integrity of your application's data from user tampering is critical. Preventing web tampering is about evaluating the data that you are sending to the user and evaluating how it could possibly be manipulated in an unfavorable way. An example could be price data. Could a user modify the price of an item from an e-commerce site and successfully purchase the item with the undesirable price? This applies to all data in general, especially application specific data. It is important to be selective of what data is emitted to the client and to perform sanity checks on all data that is sent to the server. Treat all incoming data to the server with extreme skepticism. For more detailed information, please read the OWasp guide to Web Parameter Tampering.


The goal of non-repudiation is to establish thorough logging processes of user activity. The reasoning for this is two-fold. First, this is to mitigate against false claims against your company and/or services. For example, a user may try to claim they didn't transfer money through your service when they actually did. The second reason is that attackers may forge the identity of other existent or non-existent users to carry out other malicious activities. Of course, there is a trade-off in application performance so it is best to determine the logging according to your organization's specific needs. For more information, visit the OWasp guide on Repudiation Attacks.


Users place a tremendous amount of faith in the applications we build. When they submit their emails, addresses, full names, phone numbers, and financial info they expect us to take proper care of that information and keep it from prying eyes. Instead, we routinely hear news about another major breach where customer data is stolen and sold on the dark web or exposed for public shaming. There is no one cut and dry way to prevent such attacks but there are some good practices we can follow. First, we need to prevent the Web Parameter Tampering mentioned earlier. Especially with regards to preventing tampering with user IDs. Next, we need to be selective of what information will be stored in the browser. Assume that web browsers will ignore our no-cache headers and especially do not keep sensitive information in browser storage. We have to remember that web browsers carry many vulnerabilities of their own which can lead to catastrophic results.


As developers, we all know about the importance of uptime for our apps and services. Despite all the effort we put into making our apps more performant and stable, there lies the infamous Denial of Service attack. In handling this, it is key that we remain aware of any CPU intensive portions of our cloud services. Check for large calculations, heavy searches, big queries, and large file transfers (both incoming and outgoing). If we identify any of these, make sure that they are reserved for authenticated and authorized users only. It is also worth checking our code for vulnerabilities. Two key vulnerabilities to look for would be as follows...

  1. Make sure any for loop counters are not able to be determined by user input such as this...

for (var i; i < userDefinedNumber; ++i;) { 



  1. Make sure users are not able to arbitrarily determine the number of objects allocated in a function within your service.

For a more in-depth look at preventing Denial of Service attacks, please review the OWasp guide to DoS attacks.


This is distinct from authentication as authorization is about determining distinct user roles in your service. For example, you may have a user role, then an admin role. However, the chief threat is that a user may try to escalate their privileges. This is why it is critical to pass all actions through an authorization matrix to ensure only authorized users are performing the actions allowed for their role. For a more detailed walkthrough, check the OWasp Privilege Testing Guide.


As you can see, while preparing the security of our production applications can be a complex task. We can utilize STRIDE to give us a methodical way of tailoring our security needs on an individual basis. For those wanting more information, check out the OWasp Threat Modeling Guide.