Have you ever been surprised by a web security report pointing out vulnerabilities in your application? If so, count yourself fortunate. There's a vast array of security risks out there that you might not have even considered yet.
As frontend developers, we play a crucial role in safeguarding the applications we create. This becomes a priority when we deploy an application that is available for any internet user.
In this article, we're diving deep into the world of vulnerabilities – understanding what they are, why they evolve, and how knowledge of them helps us to better protect our applications and their users. Toward the end, I'll share some valuable resources that I feel are a good entry point to learn more.
Understanding vulnerabilities
Security vulnerabilities are essentially weaknesses within our application that can be exploited by attackers to cause harm. These can range from minor issues causing negligible disruption to severe flaws that could compromise sensitive user data or system integrity.
Why do vulnerabilities change over time?
Vulnerabilities change as technology advances. Existing issues may become obsolete or adapt to changes. Hackers always find new ways to break into systems. Developers and security professionals need to keep up and establish innovative defenses.
In addition, today's web applications are highly complicated. They use many services and features, which introduces additional security challenges. This makes it extra hard to keep web applications safe.
Here, you can read more about our frontend services.
TOP 10 API security threats by OWASP
While reading about web security, there are frequent mentions of the Open Web Application Security Project (OWASP). This is a non-profit organization that helps raise understanding and improve the security of software. The main document that you might see in circulation is the OWASP Top 10.
In 2023, OWASP updated API Security TOP 10 its essential insights into current security threats and how to address them. This list is a key resource for developers aiming to build safer web applications.
Top 10 threats list, by OWASP:
- Broken object level authorization
- Broken authentication
- Broken object property level authorization
- Unrestricted resource consumption
- Broken function level authorization
- Unrestricted access to sensitive business flows
- Server-side request forgery
- Security misconfiguration
- Improper inventory management
- Unsafe consumption of APIs
The list is lengthy, and thoroughly examining every item at once would be an enormous task. Let's focus on verifying the first two threats from the list in depth.
Number 1: Broken object level authorization (BOLA)
Security risk:
Broken object level authorization
OWASP description:
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.
What does it mean?
Users can access objects and information within it that should not have been exposed to the user.
Let's imagine we have a company application accessible to all its employees. This application includes a page where users can view all their contract details. While inspecting the network requests through browser developer tools, a user - John Smith - discovers the API endpoint that the page uses to fetch this sensitive information: /contract/johnsmith/contract_details.json. Curious, the user replaces ‘johnsmith’ with the name of a colleague, ‘janedoe’, to access the equivalent URL: /contract/jannadoe/contract_details.json. To their surprise, there is no 403 Forbidden Error - the request is successful.
John recalls an occasion when they received a corporate email where all recipients were visible, instead of being in a group or blind copied. Utilizing the list of names from the email, the user writes a simple script to iterate through those names, fetching the contract details for the entire company through the API.
What could we do to prevent that?
In this scenario, the API endpoint must be exposed for the user to get all his/her details.
- Use random identifiers
Instead of predictable identifiers like usernames (e.g. johnsmith), use UUIDs (e.g. 857294d7-24ed-4578-89db-c34bb70353ef). This approach makes it significantly more challenging for users to guess the identifiers of other entities. It is important to note that using UUIDs alone might not be fully secure. An identifier could be obtained from another place in the application (e.g. user lists). - Implement robust authorization mechanisms
Ensure that users can only access data they are explicitly authorized to view. This can be achieved through role-based access control (RBAC), where access is granted based on the user's role within the organization, or permission-based access control (PBAC). These options provide more granular access control based on specific assigned permissions, authenticating users and verifying their permissions with each request; possibly through the use of JWT tokens. - Restructure API endpoints
Consider designing your API endpoints to abstract away the reliance on user-specific parameters in the URL. For instance, an endpoint like contract/contract_details.json could serve a user's contract details without explicitly requiring the user's identifier in the URL. The server can determine the user's authorization to access the data based on the JWT token sent with the request.
Number 2: Broken authentication
Security risk:
Broken Authentication
OWASP description:
Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume another user's identity temporarily or permanently. Compromising a system's ability to identify the client/user compromises API security overall.
What does it mean?
If there is a flaw in the authentication process which verifies the user's identity, and this authentication mechanism is exploited, the system is unable to detect the attacker and distinguish their actions from those of a legitimate user. This is a severe issue because all API endpoints could be vulnerable to attack.
Imagine our company has a website that allows employees to log in using credentials, including a username and password. Typically, the username is either generically created for each employee or their email address, which can be easily discovered. Using scripts, an attacker can perform a brute-force attack by making multiple login attempts in a short period, trying to guess the correct password.
Once the attacker successfully gains access, they can access the victim's data. Moreover, being authenticated as a user gives the attacker more opportunities to discover additional vulnerabilities within the system.
The attacker can find out the JWT token structure and try to modify it for their own purposes, by adding additional permissions or identifying as another user.
What could we do to prevent that?
- Apply anti brute-force mechanisms
Maintain logs of authentication attempts. Prevent multiple login attempts without implementing a lockout mechanism or requiring a CAPTCHA challenge. Ensure that only strong passwords, which are harder to guess, are allowed. - Secure credential change
If your application allows users to modify their usernames or passwords, always request the current password for confirmation. Ideally, implement two-factor authentication (2FA) as an added layer of security in case a user's password is compromised. - Validate tokens
Ensure the authenticity of tokens by using official third-party libraries. Do not accept unsigned or weakly signed JWT tokens. Also, check the expiration date of each token to ensure it's still valid. - Secure saved passwords
When saving users' passwords, always encrypt them. Never store passwords in plain text and prevent unauthorized access to sensitive information. - Use open-source solutions
Often, the best option is to adopt well-maintained third-party solutions. Even when trying to secure the authentication process, it's possible to overlook potential vulnerabilities. Moreover, staying up-to-date with new security threats is essential. I've used Keycloak
for handling authentication, storing users and their passwords, and integrating with external identity providers (e.g. Google, Okta, Azure).
Summary
The two security risks mentioned above are among the most easily exploitable, widespread, and severe in impact. Both are easy to detect. The topic of frontend security is extensive and complex. Grasping the full scope of these issues and implementing effective security measures is challenging. A practical approach to better understand and address these problems is through ethical hacking. I recommend visiting PortSwigger and exploring their learning paths. This resource is free and offers structured paths in server-side, client-side, or advanced topics, complete with hands-on laboratories for immersive learning.
