[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?