authorization
Safeguard articles tagged "authorization" — guides, analysis, and best practices for software supply chain and application security.
44 articles
Nobody Chose to Fail Open. The Catch Block Did.
A permission check that throws, times out, or returns something unexpected proceeds as though access were granted, because a broad catch block written to handle an operational problem silently became an authorization bypass.
The Permission You Just Revoked, According to a Replica That Has Not Heard Yet
A user is removed from a project. The write succeeds on the primary immediately. For the next several hundred milliseconds, a read replica still shows them as a member, and if any authorization check reads from it, they can still act.
Authorization Belongs in the Tool, Not in the Prompt
Your support chatbot can now issue refunds and look up orders, because someone connected it to real tools. Every one of those actions sits behind a customer-facing text box, protected however carefully the prompt was worded.
Your Old API Version Is Still Serving and It Did Not Get the Fix
You shipped v2 with a tightened authorisation check. v1 is still live because nobody knows who calls it. An attacker does not have to use v2.
A Deep Link Is an Unauthenticated Entry Point Into Your App
Anything can send one: a web page, a QR code, a message, another app on the device. With a custom scheme there is not even a guarantee the link reaches your app rather than someone else's.
A WebSocket Is Authorised Once and Then Lives for Hours
The user is removed from the project, their role is downgraded, their session is revoked. The socket is still open and still receiving, because nothing re-evaluates a connection that was authorised in the past.
GraphQL Moved Your Authorisation Checks and Most Teams Left Them Behind
In REST an operation has one endpoint, so the check has one place to live. In a graph a field can be reached by many paths, and a check on the top-level query does not protect the same data reached as a nested field.
A Feature Flag That Disables a Control Is a Control You Do Not Have
Added during an incident to skip a validation or bypass a limit, intended to be reverted that afternoon, and nothing reminds anyone. It lives in a system with weaker access control and no change record than your permission model.
Your Queue Consumer Is an Endpoint Nobody Reviewed
Your API validates every request and authenticates every caller. Behind it a worker reads messages and acts on them with none of those checks, because internal is trusted. That worker takes untrusted input and performs privileged actions.
Your ChatOps Bot Is an Admin API Nobody Reviewed
It deploys, restarts, queries production and rotates keys, and the authorization check is whether the person is in the channel. It became powerful one useful command at a time, and none of them got the review a new admin API would have.
Permission Models Are Not Designed, They Accumulate
An is_admin boolean, then a role column, then a special case for one customer. Three years later nobody can say what a given user can do without reading the code, and an auditor is asking.
Writing an MCP Server That Holds No Credentials
Give a model a tool that writes and you have added a route into whatever sits behind it. The design that keeps it a new shape rather than a new privilege, and the four things that were not obvious.
Self-healing security runs on Safeguard.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.