[godelski]

  > The Inherent Insecurity of API Connections

I'm no security expert, but this seems like a bad take. How are APIs any less secure than any other form of interacting with a program? Nothing here is really a problem with APIs but rather a problem with access control.

  > anyone with Reader permissions on the connection is allowed to arbitrarily call any endpoint on the connection

This is not an API issue... It feels like saying we shouldn't allow users to search a database because they might run a SQL injection to drop all the tables. Searching tables isn't the problem, not sanitizing inputs is. This is more like giving all users on your network sudo access or just doing chmod -R 777 /.

My concern here is that a lot of people have the takeaway that APIs shouldn't be exposed because they create security risks. But that's not true. The API exposure isn't the risk, it is the access control. If you don't have proper access control then it really isn't going to matter if you have an API or not. But then again, we have a long history of not taking fairly basic security seriously and with decades of computing and seeing the results, I really can't figure out why. Sure, security is expensive, but bad security is far more expensive. I guess maybe the issue is I'm not much of a gambler.

[twisteriffic]

I think you misunderstood what was meant by "API connections". In azure, they're an entity that is created to represent connectivity to some external service, usually bundled with credentials and the OpenAPI definition of the downstream service. They let you consume an external service from other azure services without having to worry about things like token refresh. The article goes into better detail on this than I can in a comment.

[godelski]

I did read the article and I'm not sure why this isn't about access control

  > it is common to not mark input (and output) as sensitive.

There's 2 solutions to this:

  1) Fail open: default setting is that things are not marked as sensitive and an active decision has to be taken to mark sensitive
  2) Fail closed: by default things are marked sensitive and action needs to be taken to mark it as non-sensitive

Another way of seeing this is that 2 is the common paradigm of "least privileges." You give users, files, services, whatever the minimal privileges required.

  > What I would not expect is that anyone with Reader permissions on the connection is allowed to arbitrarily call any endpoint on the connection:

To me this sounds like doing `chmod -R +r /`. Or as the author puts it

  > all Readers on that subscription can call all GET requests defined on the connection.

This is certainly an access control issue. Even if the issue is that Azure doesn't allow for more fine grained access control, it is still access control. So that's what I'm not getting. It is about having the ability to do API calls, to do GET and POST commands, it is about tokens (accounts) having more privileges than they should.

What am I missing here?