The API Churn/Security Trade-Off (2016)(intercoolerjs.org)
intercoolerjs.org
The API Churn/Security Trade-Off (2016)
https://intercoolerjs.org/2016/02/17/api-churn-vs-security.html
7 comments
We know about mTLS. Nobody does it because it's just too painful.
We do that at scale
Too painful ? It is just regular TLS
Too painful ? It is just regular TLS
Aaaayyyy yooo, i wrote this a long time ago, but I think it holds up!
TLDR: there is a trade off in how much expressive power you can surface to front-end developers when their logic is written in-browser because anything you give to them, you give to anyone who can open up a console. That makes things a lot more dangerous and is in contrast w/ the back end, where you can give developers access to a full SQL implementation.
TLDR: there is a trade off in how much expressive power you can surface to front-end developers when their logic is written in-browser because anything you give to them, you give to anyone who can open up a console. That makes things a lot more dangerous and is in contrast w/ the back end, where you can give developers access to a full SQL implementation.
At the end of the day, it's still only shuffling around where you define your constraints, because you need them either way. Whether you define a rigid API endpoint for the frontend (named the problem in the article) and handle access control there, or make the API fluid with e.g. GraphQL (the first solution in the article) and define access controls there, it's still the same problem.
I don't agree with that.
You can give a back end developer SQL, because the users of your application don't also get SQL. Not true of GraphQL.
You can give a back end developer SQL, because the users of your application don't also get SQL. Not true of GraphQL.
intercooler.js is the forerunner of htmx.org - by the same author
>The problem with these increasingly expressive end points is that you are putting them not just in the hands of your front end developers, but also in the hands of potentially hostile users.
Meaning, let's not expose to 'hostile users' if we can help it.
For example, put the API gateway solely on a private overlay, and gate entrance to that overlay to endpoints with enrolled private key signed certs (+ other factors if you wish).
Puts more burden on the API clients - e.g. PKI enrollment, management, etc. would need to be reliable, automated and abstracted.
So infeasible or too much friction for some APIs, but this would reduce the attack surface for a B2B API with a limited number of consumers...and many of those would take that tradeoff?
Of course, we still wouldn't 'trust' the private network overlay in our API definitions...it would just be one more layer of security if access is gated with modern cryptography.