One of the first principles developers learn when writing REST APIs is to use GET for retrieving data and POST for modifying data.
Except, of course, GET exposes the parameters in the URL directly. And we never want to expose sensitive data like user credentials, PII, or PIFI. So they immediately must un-learn what they have learned, and put sensitive data in the body, using POST, to provide a slightly better default security and privacy posture.
In an attempt to mitigate the risk, some organizations create policies to make using GET requests so cumbersome to deploy - with additional security checks and review queues - that they effectively ban them from use.
Which, in turn, creates downstream problems. When all the requests are POST, then all the requests can modify the data. This gives many API users a lot of discretion and power.
In the end, of course, the right way to solve the problem is to tokenize sensitive data, so it can be transmitted using any API call.
But, as applications improve tokenization and context-awareness, we are left with a patchwork of half-secure, mostly-private applications talking to each other. Older applications may run on SSL or an outdated version of TLS. Rogue application developers may find ways to accidentally push unsecured http requests live. Relay APIs may sit outside of the security perimeter.
In addition, external API consumers may only have GET permissions, they can consume data but they can’t change it. Or, an API call may not have a specific method defined, in which case many services will assume the request should be a GET request.
If only one element is misconfigured, personal data is exposed, which is a security breach and also a privacy breach.
It’s critical to improve the awareness and visibility of these security and privacy gaps, in order to make incremental improvements across the entire system. We need to be able to fixing privacy and security in post…by monitoring how actual calls are made in real, live operational systems.
Top comments (0)