Eliminating API Authentication and Access Control Security Gaps
There’s a reason weak authentication and access control is first on the OWASP API Security Top 10.
Join the DZone community and get the full member experience.Join For Free
Traditional applications (almost) always have strong authentication and access controls in place to help safeguard data. APIs – which help transmit or provide access to sensitive information – should also all be protected to the same extent, especially when you consider that an API is all-inclusive, sending data and executing functionality. Unfortunately, the recent rash of API security incidents demonstrates that appropriate security controls have not been implemented. The most common security gap across all of the recent API security incidents is weak authentication and access control. In fact, it’s listed as #1 on the OWASP API Security Top 10.
- Authentication is the process of verifying the identity of a user who wishes to access the system. In order to protect critical data, API developers must have a firm understanding of what data an API is transmitting. Developers must work closely with API owners to choose an authentication technique equal to the value of the data. For example, basic authorization, API key-based authorization, and OAuth are several options defined by the Swagger/OpenAPI specification 2.0.
- Access Control is the process of controlling access to a resource once the user identity is authenticated. In addition to API authentication, it’s critical that developers control and keep a close eye on an ongoing basis to who has access to these APIs. Users must be contained within their own authorization profiles, as without proper access controls there could be application-level privilege escalation resulting in regular users performing administrative tasks, or lateral movements where an authenticated user can access other users’ information.
Uncovering Security Gaps
There is no one reason why APIs are released without proper authentication and access control, but a few possible causes might include:
- Development teams have not received training on secure coding for modern applications or for APIs. Security training for developers has long been a challenge, and the flexibility that APIs introduce exacerbates this challenge. Developers are human. Errors are made. However, more complete and API specific training may lessen the frequency of errors.
- Inadequate security testing was performed on the API functionality. Many organizations perform application pen-testing, but too often the API functionality is not tested from a security perspective.
- The API was originally intended to be an internal API, behind multiple levels of security, yet it was exposed either accidentally or purposely without knowing about the lack of authorization and the inherent security risk. Many organizations are adopting the security best practices approach that treats all APIs as external, which means tighter controls and fewer risks.
- The API is a shadow API, released outside of the defined process, so peer review, QA cycles, security testing may not have been applied. If this is the case, then the specifications may have been summarily ignored. Worse yet, often these systems are built at full “admin” level and everyone is an admin.
The “shift left” paradigm that organizations are embracing is designed to catch these types of security gaps early on in the DevOps process. To support this effort, organizations are implementing checks and balances that happen within each part of the development phases, including secure coding training for API developers; well-defined features and functional specifications that include security, code reviews and security audits; Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). By instilling this system, potential incidents are often caught before publication or discovery of the API, helping to mitigate the risk of a security incident.
How Visibility and Monitoring Can Help
Authentication and access control are critical when it comes to protecting APIs, and both of these safeguards are easier to manage when an organization has full transparency into its API footprint. Additionally, full transparency can help with continuously monitoring the API landscape, providing answers to questions, including:
- How many APIs does our organization have and who owns them?
- Have the appropriate levels of authentication and access control been enabled?
- What type of data are our APIs transmitting? Are our APIs using encryption?
Protecting the critical data APIs transmit or provide access to requires an expanded understanding of how the API works, who the users are and what data is being accessed. With runtime API visibility and monitoring, enterprises can answer these basic questions to strengthen their API security posture and help to mitigate risks now and in the future.
Opinions expressed by DZone contributors are their own.