Security Misconfiguration

What does this vulnerability consist of?

Security-conscious developers may implement a myriad of security systems for their infrastructure and their APIs, however – as we’ve seen in some places in this list – a misconfiguration of security systems can be as dangerous as their complete absence. The reason for this is twofold: first, it allows malicious actors to bypass implemented systems, and second, it instills in developer and maintainer teams a false sense of security. It is therefore crucial that not only are the correct systems implemented but that they also are configured properly.

What is the potential impact?

Consider a company’s long-forgotten API accessible at a subdomain whose access from the internet was not disabled by the company’s developer and IT teams. Using OWASP Amass (which is a great tool, by the way), a malicious actor finds the API that can serve personally identifiable information about users within the company. Since the API has been forgotten and therefore not maintained, critical security patches have not been applied, which leaves the API open to exploitation using known vulnerabilities. Either rendering the API inaccessible or otherwise keeping it regularly updated would avoid this potential PII data leak.

What do the misconfigurations look like?

Security misconfigurations come in all kinds of shapes and sizes. The basic misconfigurations include not having the latest security patches applied. This can be at the OS level for the machine that hosts the API, or for the API itself (e.g. a patch for the language used to write the API). Another important misconfiguration to address is divulging detailed error logs that can offer insight into the API design, which can provide all the clues for a malicious actor to tailor their attack approach to a specific API. The OWASP API Security Top 10 report also mentions a missing Transport Layer Security (TLS), enabling unnecessary features (such as HTTP verbs – GET, POST, PUT, DELETE), and a missing or improperly set Cross-Origin Resource Sharing (CORS) policy as important security misconfiguration issues to address.

How can you protect your API?

The mitigation of security misconfigurations should be carried out at various stages during the API development cycle and deployment cycle. Besides developing APIs with security in mind, the OWASP report strongly suggests implementing a “repeatable hardening process leading to the fast and easy deployment of a properly locked down environment.” Once the API is operational, it is important to continuously assess and review its security configuration as programming languages and other technologies keep evolving. Specifically, the review should be conducted at set time intervals with special iterations when a critical vulnerability is patched and should include “orchestration files, API components, and cloud services (e.g., S3 bucket permissions).”

While this review can be conducted manually, OWASP recommends implementing an automated method for this. Furthermore, unused HTTP verbs should be disabled to avoid a malicious actor accessing the API in an authorized way, and “APIs expecting to be accessed from browser-based clients (e.g., WebApp front-end) should implement a proper Cross-Origin Resource Sharing (CORS) policy.” Following these steps will ensure that the API security features are properly implemented, making malicious actors’ work a lot more difficult and securing the API and the information it contains or accesses from malicious actors.

In the end, security misconfiguration is a lot like insufficient logging and monitoring: these are the first steps in securing APIs, and as a result, it is extremely important to properly implement them, as it will significantly help in thwarting attacks and mitigating damage.