The Open Worldwide Application Security Project (OWASP) is a global community that champions the cause of application security. OWASP seeks to educate, connect, and empower security professionals. It holds trainings and events. It publishes immensely helpful guidance on all things “appsec,” including through its excellent cheat sheet series. But what truly makes OWASP a household name, at least among the ISE team, is its top 10 project.
Every few years, OWASP publishes a new OWASP Top 10 list, “a standard awareness document” that “represents a broad consensus about the most critical security risks to web applications.” In recent years, OWASP has branched out a bit, developing top 10 lists for areas such as mobile application and AI/ML security. However, its web application list remains the best known and most closely reflects the findings of our assessment work.
Like the rest of the security industry, the ISE team has been eagerly awaiting the release of the newest OWASP Top 10, slated for November 2025. After all, the OWASP lists provide a snapshot of the security landscape—a peek at the vulnerabilities other security professionals are finding—so how could we not be curious?
Eventually, though, we started getting a little impatient—and started thinking about what we’d put on the list if it were up to us. What issues were we seeing again and again? What risks did we want our clients, and the larger community, to be aware of? How would we improve the OWASP Top 10: 2021?[1]
What would the ISEWASP Top 10 be?
The Creation
Since publishing its first top 10 list in 2003, OWASP has developed a fairly rigorous data-driven process for identifying and then ranking the risks worthy of inclusion.
The development of the ISEWASP Top 10 was a less scientific endeavor.
Like many initiatives at ISE, the selection of our top 10 risks was a group effort—the result of team discussions. The process also involved a review of many of our recent assessment reports, with the goal of identifying issues that popped up again and again. And to be completely transparent, we did give a bit of thought to—well, let’s call it “interestingness.”
Once we had selected our 10 risks, our analysts gave each risk a score from 1 to 10 on the basis of its exploitability and technical impact. We then tallied up those scores and ranked the 10 options, assigning the risk with the lowest score the (not so) coveted #1 slot.
The List
1. Lack of Access Controls
If you’re familiar with the 2021 edition of the OWASP Top 10 (or the 2017 edition…or the 2013 one), you’re probably not shocked that the ISEWASP Top 10 begins with an access control issue. But it’s a classic for a reason: A lot of systems lack proper access controls. In other words, they allow users (and attackers) to access information they shouldn’t be able to access or perform actions they shouldn’t be able to perform.
Some, for example, lack access controls on privileged admin functionality. They may prevent non-admin users from executing privileged operations through the UI but allow them to do so by sending direct requests to the associated endpoints. Others lack horizontal access controls, meaning that users can gain unauthorized access to data or resources belonging to other users of the same privilege level. In an application that allows users to upload images, for example, that might mean that Bob can access any image uploaded by Alice as long as he can guess the ID assigned to the image.
2. Broken Authentication Flows
This one’s another classic.
Like access control issues, broken authentication flows can allow attackers to access things they shouldn’t be able to access. But in this case, those things are often legitimate users’ accounts.
Not good.
But what exactly do we mean by “broken authentication flows”? What kinds of issues are we actually seeing on a regular basis?
I'm so glad you asked. Here are two of the big ones.
→ A lack of rate limiting on login endpoints: Password-guessing attacks often rely on the ability to rapidly submit numerous login requests. In a brute-force password-guessing attack, for example, a bad actor with knowledge of a valid username attempts to identify the associated password through trial and error. The attacker uses a script or tool to submit one login attempt after another, trying out every possible password until finally, one is accepted.
Implementing a limit on the number of login attempts that a user can make within a certain period—that is, implementing rate limiting—can prevent brute-force attackers from making enough login requests to find a valid password.
To put it plainly, rate limiting can stop them in their tracks.
→ Weak password policies: A lack of rate limiting on an application’s login endpoint can make brute-force attacks possible—and a weak password policy can make those attacks much easier.
There’s a subset of brute-force attacks called dictionary attacks, in which attackers use common simple passwords rather than every possible password in their login attempts. An attacker might try to log in to a user’s account with passwords like “1234” and “password,” for example. (So if you use one of those passwords for any of your accounts, please go change it now! And maybe consider using a password manager.)
As you might guess, creating a strict password policy that requires users to set long, complex, unique passwords is a pretty effective technique for preventing dictionary attacks. Combining that technique with multifactor authentication (MFA)—that is, requiring the user to provide a second factor of authentication, like a unique code sent to their email address or cell phone—significantly increases its efficacy. The use of MFA means that an attacker must identify a user’s password and provide a valid second factor of authentication to gain access to the user’s account.
3. Server-Side Request Forgery
When creating its list of the top web application risks, OWASP analyzes vulnerability data from organizations in the industry and selects 8 of its 10 risks from that data. The remaining list entries are essentially crowdsourced, chosen through a community survey.
Server-side request forgery (SSRF) is one of the crowdsourced issues on the OWASP Top 10: 2021. It was included because, according to OWASP, “security community members are telling us this is important, even though it’s not illustrated in the data at this time.”
Well, we agree with the community.
SSRF vulnerabilities are no joke. They enable attackers to access resources or systems that they shouldn’t be able to access by tricking the server into executing requests it shouldn’t execute.
These vulnerabilities typically occur when an application allows users to specify the target of a server-side request. For example, say that an application lets users upload images for their profile pictures by providing the images’ URLs. When the server receives a user-provided URL, it fetches the content at that URL, and the image becomes the user’s profile picture. The problem arises when an application fails to validate that URL—that is, it fetches the content at that location regardless of what it is. As a result, an attacker can provide the URL of other content, such as a sensitive internal resource, and the server will fetch that instead.
4. Anonymous Access to Sensitive Simple Storage Service Buckets
Many of the web applications we assess rely on Amazon Web Services (AWS), a massively popular provider of cloud computing services such as Identity and Access Management (IAM), Elastic Compute Cloud, and Simple Storage Service (S3).[2]
It’s no surprise, then, that our assessments often yield at least a few cloud configuration issues. Most of the common AWS issues we find are relatively minor—more security-hardening opportunities than true vulnerabilities. One, though, is much more significant, not only in its impact but also in its exploitability.
It requires some explaining, though, so bear with me.
S3 is a file storage service that allows users to store objects (documents, media assets, activity logs, etc.) in containers known as buckets. S3 offers users pretty granular control over access to their buckets, allowing them to manage their resources through IAM policies and bucket-level policies (as well as through access control lists, though AWS now discourages their use). A bucket policy grants or denies principals (users, accounts, or other entities) permission to perform actions on the associated bucket, such as adding new objects or retrieving existing ones.
And now we arrive at the crux of the issue: The Principal element of a policy does not need to be set to a specific entity or entities. It can be set to the wildcard character (*), which signifies, quite literally, all users, including anonymous users on the public internet.
Maybe you can guess where this is going. Some highly sensitive S3 buckets—buckets that store proprietary documents, prerelease media content, or patient health data, for example—have bucket policies that unintentionally grant permissions to everyone on the internet. Anyone at all can perform the actions that those policies allow—no hacks, niche tools, or complicated exploits required.
Yikes.
5. Insecure File Uploads
The ISE team assesses a lot of content management applications—applications that allow users to store, share, review, market, distribute, collaborate on, or otherwise work with video, text, or image content. Of course, if a user is going to manage their content through an application, they need a mechanism for getting their content into that application. And that mechanism is often less than secure.
There are two file upload issues that we see time and time again, and they’re almost always a package deal: a lack of file upload restrictions and a lack of malware scanning on uploaded files. The first means that users can upload potentially dangerous files—massive files that could cause a denial of service, HTML or XML files that contain malicious payloads, or files with spoofed extensions, for instance. The second means that those files won’t be scanned for malware, so if they do contain something malicious, it won’t be detected.
In addition to posing a significant risk to applications, this pair of vulnerabilities can have a direct impact on users. In an application that allows users to share content with one another or to download uploaded files, an insecure file upload mechanism can quickly become a conduit for malware.
6. Weak or Missing Content-Security-Policy Headers
A Content Security Policy (CSP) is a security mechanism that can provide an additional layer of protection against certain attacks. Defined in the Content-Security-Policy response header, the mechanism allows a server to control the use of risky HTML features and to implement restrictions on the loading of resources such as images and scripts.
A CSP doesn’t prevent the introduction of vulnerabilities, but it can prevent the exploitation of those vulnerabilities. For example, a CSP can prevent the execution of inline JavaScript, making any cross-site scripting vulnerabilities in an application much more difficult to exploit. Similarly, it can stave off clickjacking by limiting the domains that can embed an application’s content within a frame.
However, we also see CSPs that allow resources to be loaded from any origin or permit the use of the eval() function, which executes JavaScript from a string and should never (ever!) be used. And then there are the applications that don’t send the Content-Security-Policy header at all, which is a bit like choosing not to wear your seat belt; it won’t cause a car crash (a vulnerability), but if a crash does occur, you’ll be unlikely to walk away scot-free.
7. Open Redirects
In an SSRF attack, a bad actor tricks a server into retrieving a sensitive internal resource or connecting to an external system by manipulating the target of a request. Open redirect attacks also involve the manipulation of requests, though in this case, they’re redirect requests.
Open redirect vulnerabilities occur when an application redirects users to a site or application page without validating the redirect target (the destination). For example, say that an application redirects users to its login page when they log out or become inactive. The application might do that by sending a GET request to the /authentication/logout endpoint, with a request line that might look something like the following:
GET /authentication/logout?redirectTo=/login HTTP/2
When the request is processed, the user is redirected to the destination specified in the redirectTo parameter, which, in this case, should be the login page.
However, the application fails to check that the redirectTo parameter actually points to the login page. It simply redirects the user to the destination in that parameter, trusting that it’s the intended redirect target rather than, say, a destination on another domain.
Then one fateful day, an attacker notices the vulnerability—the failure to validate the redirectTo value—and creates a site that looks like the application’s login page. The attacker also crafts a URL that will result in a redirect to that site, such as the following:
https://vulnerableapp.com/logout?redirectTo=https://attacksite.com
The attacker then tricks a user of our vulnerable application into clicking on that URL, at which point the application redirects the user to the malicious site. And when that poor unsuspecting user reaches the site—which looks just like the application’s actual login page!—they enter their application credentials without a second thought, exposing them to the attacker.
8. Lack of Server-Side Session Invalidation
A session is the period during which a user interacts with an application. It begins when the user logs in and ends (well, should end) when they log out, stop using the application, or perform a sensitive action like a password change.
Sessions are necessary because the HTTP protocol is stateless. In other words, when Bob performs an action in an application, triggering a request, the server that receives the request doesn’t automatically associate it with Bob’s previous actions. Sessions solve that problem by essentially saying “Hey, server. It’s Bob again. Remember him?”
So what’s the problem?
Applications often fail to fully invalidate user sessions after logout. They may invalidate them on the client side (i.e., remove session cookies from users’ browsers) but not on the server side. As a result, if an attacker steals Bob’s session cookie during an active session, the attacker will be able to use it even after Bob has logged out, until the session expires. The attacker will be able to do everything that Bob can do in the application, because, from the server’s perspective, Bob and the attacker are one and the same.
9. Information Disclosure via Verbose Error Messages
No matter how hard we may try to avoid it, failure is a part of life. It’s inevitable. What matters, as they say, is how we deal with the failures we encounter and the mistakes we make.
The same is true for web applications.
When an application encounters an error—when a user enters unexpected input or a request includes an invalid JWT, for example—it should return an error message that will help the user figure out what went wrong. However, that error message needs to strike the right balance between being helpful and being too helpful; it needs to provide information that will be useful to legitimate users but not attackers.
A lot of web applications don’t get that balance quite right. Some respond to invalid input by returning a full stack trace—a lengthy message that details the chain of function calls that led to the error. Others return messages that disclose the structure of their SQL queries, helping attackers craft payloads for SQL injection attacks. Stack traces and verbose error messages may also disclose the names and even the versions of certain libraries used by an application. And while information like that isn’t necessarily problematic, it’s pretty helpful if you’re an attacker looking for known vulnerabilities to exploit.
10. Insufficient Documentation
Let’s begin this one with a disclaimer: When the ISE team started discussing the risks we’d include on our ISEWASP list, none of our analysts mentioned anything about documentation.
I’m not an analyst, though. I’m ISE’s technical writer, and I’m taking some creative liberties with this one.
The ISE team reads a lot of documentation. There’s cloud services documentation. READMEs. Man pages. User guides. And, perhaps above all, documentation on the systems we assess. However, unless we’re doing a design analysis or documentation review, we don’t generally report documentation issues. If we have questions about client documentation or find discrepancies in it, we’ll of course reach out to the client, but those issues aren’t exploitable vulnerabilities, and they’re not typically our focus.
Like I said—creative liberties.
To be clear, “insufficient documentation” doesn’t mean “documentation with a few typos or poor grammar.” It means documentation that refers to the same system in multiple very different ways or repeatedly mixes up the names of its components. Documentation that hasn’t been updated in years and doesn’t reflect current functionality. Documentation that contradicts itself or sends you following links like breadcrumbs, promising that this page or that page will have additional details on the topic at hand but failing to deliver on that promise.
I could go on, but instead I’ll leave it at this: Documentation should be clear, accurate, and up to date.
The End
And there you have it: the issues that plague web app after web app. The issues that attackers know and love. The very first edition of the ISEWASP Top 10.
We’re looking forward to seeing how the actual OWASP Top 10 measures up and will continue to wait with bated breath for its release. In the meantime, we’ve got plenty of work to keep us busy—there are assessments to do and vulnerabilities to find. And as we find them, we’ll start thinking about the next edition of the ISEWASP Top 10.
So stay tuned.
Concerned that your application might be vulnerable to the ISEWASP or OWASP Top 10 issues? ISE can help. Get in touch today for more information on finding—and fixing—the vulnerabilities in your application.
________________________________________________
[1] The obvious answer: by not making “injection” a single category. But we figured there’d be other areas of improvement, too.
[2] Okay, so this one isn’t technically a web app–specific vulnerability; it could affect any kind of application that uses S3 buckets. Nevertheless, its potential to cause big issues for web applications has earned it a place on the ISEWASP list.
