Securing API’s : Top 3 Issues
Recently I did a top to bottom analysis of a cloud provider service for their API endpoints going through all their service and their NEW services and what threat vectors they currently have what they will have going forward.
They dev team was very dismissive and the rest of the org was shocked to find out what all was missing.
For me, this was ‘par for the course’ as 41% of companies API’s were hacked last year.
Yeah, thats a shocking stat but when you consider the fact that ANYONE can BUILD AN API but practically no one understands how to secure one, that stats becomes more understandable.
So I thought I would take a some time to explain the top 3 things I look for in a security audit of API endpoints…
#1 APIDocs with No RBAC Rules
Role Based Access Control (RBAC) is used to change how data is received/returned per endpoint based on the user/role requesting. This is crucial as it keeps a USER from getting ADMIN data or requesting an ADMIN endpoint.
Now, Alot of people use Swagger/OpenAPI for their APIDocs but OpenApi (which is based on Swagger) does not support RBAC; the lead dev on OpenAPI was quoted as saying :
In other words, if you are using Swagger/OpenAPI for your APIDocs, it will show the same endpoints and request/response datasets regardless of whether you are ADMIN or USER
ISSUE: Additional traffic and attack vectors. You can avoid both the overhead of additional traffic and the possibility of these potential attack vectors if people do not see them. It is TRUE that people COULD guess them but proper RBAC implementations would still BLOCK their access. In general, if people do not have RBAC rules implemented here, one can guarantee people do not have proper RBAC implementations.
#2 API Gateway Security Rules Requires Duplication
Routing in a monolithic API application happens all within the application. API’s can route to other API’s, route to a proxy, to a MQ and back to the client (obviously). But in a distributed application, people only seem to take into consideration two ways of routing: back to the client and redirects.
I will always do a check for an ‘internal redirect’ which is something EVERY application/web server can do and is part of HTTP protocol standard. It enables the API to call another endpoint INTERNALLY within the application without going outside the DMZ.
Everytime you issue a REDIRECT, you :
- drop the thread issued for the request/response
- the call then goes outside the DMZ to route back into the system
- it hits the network where it resolves to the proxy/gateway and then your server
- the request/response is reissued and a new thread is created
ISSUE: First, going outside the DMZ can lead you open to MITM attacks; the ONLY TIME you need to use redirects is for 3rd party calls outside your network. Second, With an ‘internal redirect’, you use the existing request/response and thread so it is 200–300% faster and more secure. And finally, EVERY API Gateway provider will tell you that as a result of this pattern, you HAVE TO DUPLICATE ALL SECURITY in your application.
#3 Bad Caching
If you want to have a fast API server, you have to implement an API cache.
BUT… it is not as simple as just returning what was requested. People think thats all there is but here are a couple scenarios where this breaks everything; for example,an endpoint whose requests params & response data is different per ROLE:
- user/get for USER role doesn’t send an ID (ID is gotten from the principle retrieved via the token)
- user/get for ADMIN role can send any ID they want
ISSUE: If you just return from a cache without having an RBAC association, you will have elevated privileges EVER TIME if the last person to make that call was of a different role.
NOTE : Little known fact, if you are doing caching in your API Gateway, not a single Off-the-shelf product does RBAC caching BUT they will use RBAC with their REQUEST checking. This means that all API Gateway vendors have escalated privileges when doing caching in the gateway.
