As APIs proliferate across enterprises, so does the risk of API-induced security breaches.
While APIs introduce novel risks that haven’t been fully explored and protected against, significant progress has been made in identifying and remediating common vulnerabilities.
One such risk is Security Misconfigurations, highlighted as Guideline no. 8 in the OWASP Top 10 2023 Edition. Despite being fixable with straightforward steps, attacks related to this guideline are often overlooked, constituting 23% (the second-highest) of attack attempts.
This article outlines what security misconfigurations entail, their impact, and the steps you and your team should take to keep your APIs, company reputation, and customer loyalty intact.
In simple terms, security misconfigurations occur when custom, third-party, partner applications, APIs, or cloud services are incorrectly set up.
Ironically, security systems—when improperly configured—can inadvertently facilitate attacks instead of preventing them.
They provide attackers with an entry point into the enterprise network. This entry point is discovered during the reconnaissance phase and can be easily exploited to gain unauthorized access to sensitive data, cause data loss, or even take over the entire system.
Scanners alone cannot detect these misconfigurations, which extend beyond runtime custom applications and occur at various stages, including SDLC, third-party/partner integrations, and open-source components.
Nor can they be prevented from exploitation by WAFs and other incident response tools as they don't fall under the conventional high-volume attacks.
Inadequate monitoring leaves infrastructure vulnerable and unaddressed. For example, an overlooked API on a subdomain not secured by the DevSec team can easily lead to a PII leak.
Merely deploying multiple security solutions without customization won't prevent breaches and can worsen them. The 2019 Capital One breach occurred due to a poorly configured open-source WAF not tailored to the enterprise's specific needs.
Encryption protocols like TLS should always be used to safeguard data in transit for interception. Lack of which results in not just data sniffing but also unauthorized access, PII leak, and system takeover.
While decreased costs and higher flexibility are a result of cloud adoption then so are risks of data leaks, privacy violations, and unauthorized changes. Without strong encryption and access controls in place, all these risks are very real for enterprises that operate entirely on the cloud.
It's obvious that if you prevent a breach then you should be able to define and control who can access your systems and what they can do. When your CORS Policy is unaligned from these decisions, it leads to data leaks and unauthorized access.
HTTP headers enable secure communication between system components. Missing headers allow unauthorized requests, while unnecessary headers increase the risk of XSS attacks.
Stack traces aid internal debugging but expose functions that cause errors to attackers, making exploitation easier.
Inactive or low-activity APIs often lack proper security measures, making them easy targets for attackers. These should be promptly identified and disabled to prevent exploitation.
APIs returning more data than necessary, including sensitive information, expose vulnerabilities through headers, error messages, and status codes, aiding attackers.
Weak authentication (AuthN) mechanisms, like poor password policies and vulnerability to stuffing attacks, leave numerous endpoints unsecured. 40% of surveyed enterprises reported AuthN issues in production APIs.
Even with strong authentication, inadequate authorization (AuthZ) allows attackers to access and manipulate user records. 78% of attacks come from seemingly legitimate users with malicious intent.
A failure to implement input sanitization control often culminates into a successful injection attack allowing attackers to execute commands and access information they shouldn’t be able to.
While all of the above factors are dangerous in isolation, they are often collectively responsible for breaches. And when they are, the repercussions are intense as seen with the T-Mobile Breach last year.
Improper access controls led to unauthorized access to sensitive data and the subsequent leak of personally identifiable information (PII) of 37 million customers, including names, billing addresses, emails, phone numbers, dates of birth, and T-Mobile account numbers.
The breach, which began in late 2022, went undetected until January 2023 due to insufficient logging and monitoring. This not only damaged customer loyalty but also resulted in estimated fines of around $500 million. To prevent such incidents, it's important to follow best practices.
Your developers need continuous visibility into configuration parameters throughout the SDLC to identify and fix AuthN and AuthZ misconfigurations before production. Automation is essential for monitoring the configuration status of new APIs.
Adopt a Zero Trust Model where no entity is trusted without proper AuthN & AuthZ. This limits damage from compromised accounts and mitigates insider threats, which surprisingly account for 60% of data breaches.
Provide teams with only the API-related data they need. Infrastructure teams focus on load balancer events, product teams on APIM policy issues, and development teams on code-level vulnerabilities.
Even Though brute force attacks like DDoS, and enumeration have subsided compared to reconnaissance attacks, they still happen. Rate limiting protects APIs from brute force attacks like DDoS and enumeration. Last year, 70% of publicly acknowledged breaches involved rate-limiting abuse. Strategies include:
Even Though 70% of the public breaches last year indicated a rate-limiting abuse, a deeper analysis reveals that the core issue is that sensitive data flows are not adequately protected. And how can it be when enterprises struggle even to locate the said data flows due to API Sprawl? As a result, automation should be used to locate, protect, and test APIs carrying sensitive data flows.
Tools like Postman help ensure that consistent responses are received for all requests, but they cannot ensure that the said responses do not overexpose PII, traces especially in case of error messages.
So define output across these parameters:
And enforce them by:
This practice, if implemented at both network and application levels, could have mitigated the impact of incidents like the T-Mobile breach.
To prevent security breaches caused by misconfigurations, it's essential to continuously identify and address any issues before deployment. Levo's automated and proactive approach accomplishes this throughout the SDLC in the following ways:
Book a demo to see this live in action!
.png){kind=logo}
.svg)
.svg)
.svg)
