Decode an Azure Storage SAS token and see what it actually grants, when it expires in UTC, and whether it can be revoked at all. Nothing is uploaded and the signature is never shown.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Decode the token. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
An account SAS signed with the storage account key, valid for years, granting write and delete. There is no way to invalidate it except rotating the key and breaking every other client.
https://acct.blob.core.windows.net/c/f.pdf?sv=2022-11-02&ss=bfqt&srt=sco&sp=rwdlacupiytfx&se=2031-12-31T23:59:59Z&spr=https&sig=REDACTED
The token travels in the query string, so a single HTTP request puts the whole credential on the wire in the clear and into every proxy log on the path.
sv=2022-11-02&sr=b&sp=r&se=2030-01-01T00:00:00Z&spr=https,http&sig=REDACTED
srt includes s, so this token can list every container in the account rather than reaching the one object it was issued for.
sv=2022-11-02&ss=b&srt=sco&sp=rl&se=2030-01-01T00:00:00Z&spr=https&sip=10.0.0.0-10.0.0.255&sig=REDACTED
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
An account or service SAS is signed with the storage account key, so the only way to invalidate one is to rotate that key, which breaks every other client at the same moment.
Instead:Use a user delegation SAS, which is revocable by revoking the delegation key and is capped at seven days, or issue under a stored access policy.
Combined with there being no revocation, a multi-year token is a multi-year credential. It travels in a URL, so it lands in browser history, proxy logs and support tickets.
Instead:Hours or days. If something genuinely needs long-lived access, that is what a managed identity is for.
The token is in the query string, so one plain HTTP request puts the entire credential on the wire in the clear and into every proxy log on the path.
Instead:Always set `spr=https`.
Service-level access includes listing every container in the account. A token intended for one blob can then enumerate everything the account holds.
Instead:`srt=o` for a single object, or `srt=co` if listing within a container is needed.
Clock skew between the issuer and Azure produces intermittent 403s that look exactly like an expired token.
Instead:Omit `st`, or set it a few minutes in the past.
Not without rotating the storage account key, which breaks every other client at the same moment. That single property is why an expiry two years out is a two year credential leak waiting to be found in a log.
An account SAS and a service SAS are signed with the storage account key, so the only way to invalidate one is to rotate that key. A user delegation SAS is signed with a key obtained from Entra ID: revoking that key invalidates every token signed with it, and the lifetime is capped at seven days regardless of what the token claims. A SAS issued under a stored access policy can also be revoked by deleting the policy, and almost nobody uses one.
sv, ss, srt, sp, se, sig account SAS not revocable
sv, sr, sp, se, sig service SAS not revocable
sv, skoid, sktid, sr, sp, se delegation revocable, max 7 days
si=policyname stored policy revocableWhoever has the string has the access, and the string travels in the URL. That means it lands in browser history, in proxy logs, in server access logs, in Application Insights and in whatever the recipient pastes it into. Without spr=https a single plain HTTP request puts the whole credential on the wire in the clear.
It is interpreted as UTC whatever the timezone of the machine that generated it, which is a common source of tokens that expire eight hours earlier than intended. The start time is worth care too: setting st to the current instant produces intermittent 403s from clock skew between the issuer and Azure, and the failures look identical to an expired token.
On an account SAS the resource types are service, container and object. Including s permits service-level operations, which includes listing every container in the account. A token intended for one blob that carries s can enumerate everything the account holds.
It reads the query string and nothing else. It does not verify the signature and never will: that needs the storage account key, and a page that asked for one would be the exact thing this site exists not to be. So it cannot tell you the token is valid, only what it claims. It also cannot see whether a stored access policy still exists, whether the account key has been rotated since, or whether the account has soft delete enabled to survive a delete permission being abused. Nothing you paste is uploaded: the decoding happens in this tab.