.svg){kind=icon}
.svg){kind=icon}
Software development practices are going through an evolution with cybersecurity trends constantly changing. Today, large monolithic applications are falling out of favor, being quickly replaced by loosely coupled and modular microservices that are easier to develop, test, and scale. These services may be outwardly exposed as part of a software-as- a-service or other API offering.
Much like any other digital asset, these exposed API surfaces are open to attack. Organizations concerned with security will certainly want to ensure these APIs are included in all various security testing activities. Yet when approaching these APIs for their first assessment, many pentesting teams quickly learn their web assessment methodologies and security scanning tools don’t quite work due to surface differences. This typically results in testing teams having to fall back to manual pentesting methods and custom scripting, which impact assessment velocity and scaling — leading to poor coverage and missed potential risk.
Pentesting teams should take a serious look at their assessment capabilities to determine if their methodologies or tools have gaps; specifically in the handling of microservice, B2B, and mobile API assessment needs.
One key area to consider is how to locate, or discover, the APIs to assets. APIs are often decoupled from web properties, so web assessment tools like web crawlers and browsing proxies will be ineffective. APIs also may involve various non-HTTP protocols and data formats, such as gRpc, Thrift, Avro, etc. — tools may need to support these interaction protocols/transports before an assessment can occur. Authentication and authorization mechanisms also widely vary, ranging from static values to various dynamic tokens provided in any manner of HTTP headers, query, or path parameters.
Security teams should expect to make tool adjustments or ad-hoc implement custom handlers for authenticated session access. Once the security testing team can properly interact with the API, things will start to feel familiar. APIs and microservices are subject to many of the typical web vulnerabilities, a la OWASP Top 10; methodologies to assess for certain vulnerability types, such as SQL injection, will generally still work after some mild accommodation. More importantly though are certain attacks more particular to APIs and microservices, that are not commonly covered in standard web assessment methodologies. API-particular DDoS attacks, rate limiting/throttling bypasses, custom authentication and authorization mechanism weaknesses, and binary deserialization/parsing attacks are examples of vulnerabilities more frequently encountered in APIs compared to traditional web targets. It’s important that security assessment methodologies properly prioritize these attack types.
Overall, testing APIs and microservices does align to typical security testing processes once the proper investment is made in tool adjustments and methodology accommodation. Be sure to inquire with your third-party security assessors regarding how they approach APIs differently than typical web security assessments.
To learn more about security testing APIs, check out Jeff Forristal’s Guide to API Security Testing.
