Security First vs Api First
At the risk of further alienating myself in the Java community, I was in a chat yesterday with a couple of respected Java developers and I brought up that ‘security first’ should be prior to ‘api first’ especially when you consider that 92% of organization API’s were hacked last year.
I initially showed an issue that most API developers miss entirely leading to this 92% figure(44:40). One senior engineer responded ‘if you don’t understand the internals, you are not going to be able to debug it properly’ (44:40). This is a very genuine and adequate response to the issue.
But seconds later when I asked about whether security should be handled/considered PRIOR to API’s deployed, they discounted this and stated that security was not as important as DEPLOYING API’S FIRST because it can be ‘scary’ and people can overstate risk (44:53); this was seconds after he stated that developers SHOULD understand the inner workings and security aspects of the code they write.
Securing By Understanding Your Tools
Alot of aspects of software engineering are NOT AUTOMATED so they rely HEAVILY on the software engineer to understand ‘call flows’ and how the different libraries work together in order to properly secure.
For example, a majority of engineers do not know the differencs between:
- external redirect : used mainly for calling 3rd parties URI’s, this will drop a thread, go outside the DMX, come back in via DNS/router to your proxy/server and resissue the request/response/thread (Note: default for clearing the old thread is 60 seconds)
- internal redirect : used for routing internal calls (CORS is a prime example). Uses existing request/response/token to route to another endpoint within the existing api server.
Additionally, you have to understand how these protocols work with EXTERNAL services. For example:
- Question: If an API Gateway does an RBAC check on an endpoint and then forwards the call to your API server which in turn uses RBAC/ABA to format the response data based upon request USER ROLE in the token, is the API Gateway properly caching based on the RBAC/ABAC rules in the API server?
- Answer: They don’t. No API Gateway caches based on RBAC/ABAC datasets; if you are implementing RBAC/ABAC datasets in your API server, the API gateway will cache them but NOT DO PROPER CHECKS thus causing elevated privileges on following requests.
- Question: If I use an internal redirect in my API Server, aren’t all security checks at the API Gateway bypassed? (Note: all api servers have this capability as they use it for CORS)
- Answer: Any ‘internal redirect’/forward in the API server will bypass all abstracted security checks; this is why abstracting security to a separate service is a poor concept.
Both of these security issue are KNOWN by corporations that run API Gateways but they refuse to fix these issues even while acknowledging that 92% of org API’s are getting hacked:
Securing by Understanding Patterns
Many people just assumed that monolithic patterns could instantly transfer to distributed systems… they do NOT! If you attempt to do this, you create what is commonly referred to as architectural cross cutting concerns. A cross cutting concern in an architecture is data that needs to be shared across distributed services/systems such as :
- Business rules ( ie OpenAPI)
- Caching
- Data validation (RBAC/ABAC)
- Internationalization and localization
- Information security
- Logging
- Monitoring
- Persistence
- Real-time constraints
- Synchronization
- Security (yeah… especially this one)
All of these need to be consistent and be able to be updated/configured in a consistent manner across ALL SYSTEMS (ie synchronized). Not doing so can leave open holes in your security.
As an example, OpenAPI does not include RBAC/ABAC rules but is generated from controllers in frameworks which HAVE RBAC/ABAC rules:
This means these rules have to be ‘handcoded’ and manually maintained for each server separate from these docs leaving room for typos/mistakes/version errors/etc.
Securing Through Shared Config/Rules
OpenAPI advertises itself as this but refuses to add RBAC/ABAC which are necessary to accomplish this. Per the lead dev on OpenAPI:
This has been something that was brought up to Tony Tam (the creator of Swagger) in 2014 at a Meetup and to the creators and maintainers of OpenAPI multiple times but they refuse to fix.
OpenAPI and Postman have even ignored and blocked those trying to help address the ongoing issue:
One solution that has been provided to the community has been IOState
With this, you can make your declaration and include RBAC/ABAC rules which can be used across all server instances.
Security First Is NOT SCARY
Security first is not scary… we just need to start turning to professionals who have the knowledge and skills to help us to improve this in such a way as to move us to a distributed way of thinking and securing our applications.
The above has shown that corporation like Postman, OpenAPI Initiative and others deliberately block those trying to fix these security issues
To date, we have had tool makers and corporations who painted themselves into a corner and don’t want you looking at solutions that can fix these issues because it means they would lose money.
Well now it is time to fix and acknowledge the problems and start acknowledging those with the intellect and know-how for moving us in the direction we need to go.
