4 ms·
Ask HN: Is a self-MitM HTTPS proxy that injects API keys useful?
In the course of working on a side project, I've built a small HTTPS forward (i.e. egress) proxy to sit between my application servers and all external HTTP APIs. My proxy injects API keys into requests so that my application doesn't have to think about that.
My question is whether this is useful to anyone else or not? There are perhaps other useful things you could do with it, like add some observability features?
Thanks in advance for any feedback.
- jonahbenton 4y agoTypical use cases for tools like this are: - comply with egress security policies more generally - comply with rate limits and meters for costly APIs - monitor outgoing request payloads so nothing sensitive goes over the wire - caching and deduping large responses - act as the starting point for adding crawling type workloads These tend to be pretty limited and special case, and there are lots of other ways of solving each, but sometimes an egress proxy is the thing.
- tony-allan 4y agoMITM is aways wrong and dangerous! I would create a separate protected API that has an additional header such as: Forward-To-API: database-prod And have that service lookup the URL and credentials in a secure database and create it's own request to the external service. Even better it could also be your audit log. The Forward-To-API header would be stripped and the rest of the query would be passed through. -- This is so obvious that it must already exist!
- tony-allan 4y agoHard coding credentials is wrong but here is an example: http://shairosenfeld.blogspot.com/2011/03/authorization-header-in-nginx-for.html http://shairosenfeld.blogspot.com/2011/03/authorization-head...
- akerl_ 4y agoYou’ve just described an HTTP-based MITM.
- stanleydrew 4y agoI did start out this way, but I was trying to make something that would achieve the goal without requiring any changes to my application code. Setting the HTTPS_PROXY environment variable on the app server and adding the internal CA cert to the set of trusted authorities s is all that's required to get it working now, which is nice. The thing you've described is still a MitM (the "protected API" can still see all of the request contents on their way to the destination).