A Shared Access Signature token is a time-limited credential that grants scoped access to a storage resource without exposing the account key. It is typically bound to specific permissions, a resource path, and an expiry, so access can be delegated and then revoked by expiration or key rotation.
What a SAS token is in practice
A shared access signature token is a delegated access credential, not a full account credential. It is designed to grant a narrowly scoped, time-bounded permission set so a client can reach a storage object, container, or similar resource without learning the underlying account key.
That delegation model is what makes SAS useful, but it also means the token is itself security-sensitive. If it is copied, logged, or shared too broadly, the token becomes a live access path until it expires or is explicitly invalidated through the control mechanism that issued it.
How scope and expiry define the security boundary
The security value of SAS comes from its constraints: specific permissions, a specific resource path, and a specific expiry. Those constraints turn a broad storage authority into a temporary capability that can be handed to a user, application, partner, or workflow without distributing the long-term secret that backs the storage account.
That boundary is only as strong as the token design. A long expiry, permissive permissions, or a path that is broader than necessary weakens the benefit of delegation and makes the token behave much more like standing access than temporary access.
For a practical overview of where SAS fits alongside other credential types, NHIMG’s Ultimate Guide to NHIs, What are Non-Human Identities covers the broader pattern of scoped machine and application access.
Where SAS tokens go wrong
SAS tokens fail when organisations treat them like harmless URLs instead of bearer credentials. A token in a browser history, chat thread, build log, support ticket, or source file can be replayed until expiry, and an over-permissive token can expose more data than the original use case required.
They also create lifecycle risk. If the issuing key remains valid for long periods, or if shared access policies are not used where appropriate, revocation can be slower than the exposure window. In storage environments, that is why token design, key management, and logging are part of the same control story.
NHIMG’s Azure SAS Tokens Security Guide focuses on user delegation SAS, expiry policies, disabling Shared Key, stored access policies, revocation, and log detection.
Operational patterns for safer use
Safer SAS usage usually means choosing the narrowest permission set, the shortest workable expiry, and the smallest resource scope that still supports the business task. When the environment allows it, organisations also reduce dependence on account keys, prefer delegated issuance paths, and monitor storage activity so unexpected SAS use is visible.
This is also why SAS should be treated as part of secrets handling and exposure response. A leaked token often needs immediate revocation, followed by review of what it accessed and whether any downstream data or automation was touched before expiry.
NHIMG’s Cloud Storage Exposure Playbook is useful when the practical question is how to contain storage exposure, preserve evidence, and revoke delegated access quickly.
Risk and Threat Considerations
SAS tokens are attractive to attackers because they can function as portable, low-friction access credentials. If one is over-scoped or intercepted, an attacker may not need the original account key at all, only the token and enough time to use it before expiry.
Failure mechanism: The token is copied from a log, repo, message, or client-side artefact, then replayed against storage until it expires or is invalidated. Overbroad permissions or long-lived tokens enlarge the blast radius and the dwell time.
Impact: The result can be unauthorized reads, writes, deletions, data exfiltration, or persistence through continued access to cloud storage content, backups, and related operational data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | SAS tokens are bearer secrets that can leak and be replayed. |
| NHI-05 — Overprivileged NHI | SAS scope and permissions define whether delegated access is too broad. | |
| NHI-07 — Long-Lived Secrets | A SAS token's expiry directly controls its exposure window. | |
| Recommendation — Limit SAS exposure, detect leakage quickly, and revoke any leaked token immediately. Scope SAS permissions tightly and shorten expiry to reduce overprivileged access. Prefer short-lived SAS tokens and rotate the underlying keys or delegation path regularly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Delegated storage access depends on controlled issuance, review, and revocation. |
| Recommendation — Inventory and revoke delegated storage credentials when their business purpose ends. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SAS tokens function as authenticators whose lifecycle must be managed. |
| AC-6 — Least Privilege | SAS permissions should be minimized to the required storage actions. | |
| Recommendation — Manage SAS issuance, expiration, rotation, and revocation as authenticator lifecycle controls. Apply least privilege to every SAS token so only required storage actions are allowed. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SAS tokens implement controlled access to storage resources. |
| A.8.5 — Secure authentication | SAS tokens are an authentication mechanism for storage access. | |
| Recommendation — Restrict SAS token scope and review delegated access against access-control policy. Protect SAS issuance and handling so tokens are not exposed or reused outside their intended context. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Leaked SAS tokens are credentials that adversaries can steal and reuse. |
| Recommendation — Hunt for exposed SAS tokens in code, logs, tickets, and repositories as credential material. | ||
Practitioner Guidance
Why practitioners should care: SAS token design is a control decision, not just an implementation detail. The expiry, permission set, and issuance path determine whether delegation stays temporary or becomes de facto standing access.
What to watch for: Tokens created with unnecessary permissions, tokens that live longer than the business process they support, and any evidence that tokens are appearing in logs, scripts, tickets, or repository history.
Practitioner takeaway: Treat SAS as a narrowly scoped bearer credential, and review it the same way you would review any other high-value secret: least privilege, short lifetime, and fast revocation when exposure is suspected.