{
	"id": "e7c1161c-fd4f-475d-a518-5a7d881d3a7d",
	"created_at": "2026-04-06T00:21:32.508089Z",
	"updated_at": "2026-04-10T03:20:35.848869Z",
	"deleted_at": null,
	"sha1_hash": "1499c6aed5d278ebd6f1b2c832e1580aab97fe04",
	"title": "Grant limited access to data with shared access signatures (SAS) - Azure Storage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 156175,
	"plain_text": "Grant limited access to data with shared access signatures (SAS) -\r\nAzure Storage\r\nBy normesta\r\nArchived: 2026-04-05 12:51:30 UTC\r\nA shared access signature (SAS) provides secure delegated access to resources in your storage account. With a\r\nSAS, you have granular control over how a client can access your data. For example:\r\nWhat resources the client may access.\r\nWhat permissions they have to those resources.\r\nHow long the SAS is valid.\r\nAzure Storage supports three types of shared access signatures:\r\nUser delegation SAS\r\nService SAS\r\nAccount SAS\r\nImportant\r\nFor scenarios where shared access signatures are used, Microsoft recommends using a user delegation SAS. A\r\nuser delegation SAS is secured with Microsoft Entra credentials instead of the account key, which provides\r\nsuperior security. For more information on authorization for data access, see Authorize access to data in Azure\r\nStorage.\r\nUser delegation SAS\r\nA user delegation SAS is secured with Microsoft Entra credentials and also by the permissions specified for the\r\nSAS. A user delegation SAS is supported for Blob Storage (including Data Lake Storage and dfs endpoints),\r\nQueue Storage, Table Storage, or Azure Files.\r\nFor more information about the user delegation SAS, see Create a user delegation SAS (REST API).\r\nService SAS\r\nA service SAS is secured with the storage account key. A service SAS delegates access to a resource in only one of\r\nthe Azure Storage services: Blob Storage (including Data Lake Storage and dfs endpoints), Queue Storage,\r\nTable Storage, or Azure Files.\r\nFor more information about the service SAS, see Create a service SAS (REST API).\r\nAccount SAS\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 1 of 8\n\nAn account SAS is secured with the storage account key. An account SAS delegates access to resources in one or\r\nmore of the storage services. All of the operations available via a service or user delegation SAS are also available\r\nvia an account SAS.\r\nYou can also delegate access to the following:\r\nService-level operations (For example, the Get/Set Service Properties and Get Service Stats operations).\r\nRead, write, and delete operations that aren't permitted with a service SAS.\r\nFor more information about the account SAS, Create an account SAS (REST API).\r\nA shared access signature can take one of the following two forms:\r\nAd hoc SAS. When you create an ad hoc SAS, the start time, expiry time, and permissions are specified in\r\nthe SAS URI. Any type of SAS can be an ad hoc SAS.\r\nService SAS with stored access policy. A stored access policy is defined on a resource container, which\r\ncan be a blob container, table, queue, or file share. The stored access policy can be used to manage\r\nconstraints for one or more service shared access signatures. When you associate a service SAS with a\r\nstored access policy, the SAS inherits the constraints—the start time, expiry time, and permissions—\r\ndefined for the stored access policy.\r\nNote\r\nA user delegation SAS or an account SAS must be an ad hoc SAS. Stored access policies are not supported for the\r\nuser delegation SAS or the account SAS.\r\nA shared access signature is a token that is appended to the URI for an Azure Storage resource. The token that\r\ncontains a special set of query parameters that indicate how the resources may be accessed by the client. One of\r\nthe query parameters, the signature, is constructed from the SAS parameters and signed with the key that was used\r\nto create the SAS. This signature is used by Azure Storage to authorize access to the storage resource.\r\nNote\r\nIt's not possible to audit the generation of SAS tokens. Any user that has privileges to generate a SAS token, either\r\nby using the account key, or via an Azure role assignment, can do so without the knowledge of the owner of the\r\nstorage account. Be careful to restrict permissions that allow users to generate SAS tokens. To prevent users from\r\ngenerating a SAS that is signed with the account key for blob and queue workloads, you can disallow Shared Key\r\naccess to the storage account. For more information, see Prevent authorization with Shared Key.\r\nYou can sign a SAS token with a user delegation key or with a storage account key (Shared Key).\r\nSigning a SAS token with a user delegation key\r\nYou can sign a SAS token by using a user delegation key that was created using Microsoft Entra credentials. A\r\nuser delegation SAS is signed with the user delegation key.\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 2 of 8\n\nTo get the key, and then create the SAS, a Microsoft Entra security principal must be assigned an Azure role that\r\nincludes the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action. For more\r\ninformation, see Create a user delegation SAS (REST API).\r\nSigning a SAS token with an account key\r\nBoth a service SAS and an account SAS are signed with the storage account key. To create a SAS that is signed\r\nwith the account key, an application must have access to the account key.\r\nWhen a request includes a SAS token, that request is authorized based on how that SAS token is signed. The\r\naccess key or credentials that you use to create a SAS token are also used by Azure Storage to grant access to a\r\nclient that possesses the SAS.\r\nThe following table summarizes how each type of SAS token is authorized.\r\nType of SAS Type of authorization\r\nUser delegation SAS Microsoft Entra ID\r\nService SAS Shared Key\r\nAccount SAS Shared Key\r\nMicrosoft recommends using a user delegation SAS when possible for superior security.\r\nSAS token\r\nThe SAS token is a string that you generate on the client side, for example by using one of the Azure Storage\r\nclient libraries. The SAS token is not tracked by Azure Storage in any way. You can create an unlimited number of\r\nSAS tokens on the client side. After you create a SAS, you can distribute it to client applications that require\r\naccess to resources in your storage account.\r\nClient applications provide the SAS URI to Azure Storage as part of a request. Then, the service checks the SAS\r\nparameters and the signature to verify that it is valid. If the service verifies that the signature is valid, then the\r\nrequest is authorized. Otherwise, the request is declined with error code 403 (Forbidden).\r\nHere's an example of a service SAS URI, showing the resource URI, the delimiter character ('?'), and the SAS\r\ntoken.\r\nNote\r\nThe delimiter character ('?') for the query string is not part of the SAS token. If you generate a SAS token from the\r\nportal, PowerShell, Azure CLI, or one of the Azure Storage SDKs, you may need to append the delimiter character\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 3 of 8\n\nto the resource URL.\r\nUse a SAS to give secure access to resources in your storage account to any client who does not otherwise have\r\npermissions to those resources.\r\nA common scenario where a SAS is useful is a service where users read and write their own data to your storage\r\naccount. In a scenario where a storage account stores user data, there are two typical design patterns:\r\n1. Clients upload and download data via a front-end proxy service, which performs authentication. This front-end proxy service allows the validation of business rules. But for large amounts of data, or high-volume\r\ntransactions, creating a service that can scale to match demand may be expensive or difficult.\r\n2. A lightweight service authenticates the client as needed and then generates a SAS. Once the client\r\napplication receives the SAS, it can access storage account resources directly. Access permissions are\r\ndefined by the SAS and for the interval allowed by the SAS. The SAS mitigates the need for routing all\r\ndata through the front-end proxy service.\r\nMany real-world services may use a hybrid of these two approaches. For example, some data might be processed\r\nand validated via the front-end proxy. Other data is saved and/or read directly using SAS.\r\nAdditionally, a SAS is required to authorize access to the source object in a copy operation in certain scenarios:\r\nWhen you copy a blob to another blob that resides in a different storage account. You can optionally use a\r\nSAS to authorize access to the destination blob, as well.\r\nWhen you copy a file to another file that resides in a different storage account. You can optionally use a\r\nSAS to authorize access to the destination file, as well.\r\nWhen you copy a blob to a file, or a file to a blob. You must use a SAS even if the source and destination\r\nobjects reside within the same storage account.\r\nBest practices when using SAS\r\nWhen you use shared access signatures in your applications, you need to be aware of two potential risks:\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 4 of 8\n\nIf a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your storage\r\naccount.\r\nIf a SAS provided to a client application expires and the application is unable to retrieve a new SAS from\r\nyour service, then the application's functionality may be hindered.\r\nThe following recommendations for using shared access signatures can help mitigate these risks:\r\nAlways use HTTPS to create or distribute a SAS. If a SAS is passed over HTTP and intercepted, an\r\nattacker performing a man-in-the-middle attack is able to read the SAS. Then, they can use that SAS just as\r\nthe intended user could have. This can potentially compromise sensitive data or allowing for data\r\ncorruption by the malicious user.\r\nUse a user delegation SAS when possible. A user delegation SAS provides superior security to a service\r\nSAS or an account SAS. A user delegation SAS is secured with Microsoft Entra credentials, so that you do\r\nnot need to store your account key with your code.\r\nHave a revocation plan in place for a SAS. Make sure you are prepared to respond if a SAS is\r\ncompromised.\r\nConfigure a SAS expiration policy for the storage account. A SAS expiration policy specifies a\r\nrecommended interval over which the SAS is valid. SAS expiration policies apply to a service SAS or an\r\naccount SAS. When a user generates service SAS or an account SAS with a validity interval that is larger\r\nthan the recommended interval, they'll see a warning. If Azure Storage logging with Azure Monitor is\r\nenabled, then an entry is written to the Azure Storage logs. To learn more, see Create an expiration policy\r\nfor shared access signatures.\r\nCreate a stored access policy for a service SAS. Stored access policies give you the option to revoke\r\npermissions for a service SAS without having to regenerate the storage account keys. Set the expiration on\r\nthese very far in the future (or infinite) and make sure it's regularly updated to move it farther into the\r\nfuture. There is a limit of five stored access policies per container.\r\nUse near-term expiration times on an ad hoc SAS service SAS or account SAS. In this way, even if a\r\nSAS is compromised, it's valid only for a short time. This practice is especially important if you cannot\r\nreference a stored access policy. Near-term expiration times also limit the amount of data that can be\r\nwritten to a blob by limiting the time available to upload to it.\r\nHave clients automatically renew the SAS if necessary. Clients should renew the SAS well before the\r\nexpiration, in order to allow time for retries if the service providing the SAS is unavailable. This might be\r\nunnecessary in some cases. For example, you might intend for the SAS to be used for a small number of\r\nimmediate, short-lived operations. These operations are expected to be completed within the expiration\r\nperiod. As a result, you are not expecting the SAS to be renewed. However, if you have a client that is\r\nroutinely making requests via SAS, then the possibility of expiration comes into play.\r\nBe careful with SAS start time. If you set the start time for a SAS to the current time, failures might occur\r\nintermittently for the first few minutes. This is due to different machines having slightly different current\r\ntimes (known as clock skew). In general, set the start time to be at least 15 minutes in the past. Or, don't set\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 5 of 8\n\nit at all, which will make it valid immediately in all cases. The same generally applies to expiry time as\r\nwell--remember that you may observe up to 15 minutes of clock skew in either direction on any request.\r\nFor clients using a REST version prior to 2012-02-12, the maximum duration for a SAS that does not\r\nreference a stored access policy is 1 hour. Any policies that specify a longer term than 1 hour will fail.\r\nBe careful with SAS datetime format. For some utilities (such as AzCopy), date/time values must be\r\nformatted as '+%Y-%m-%dT%H:%M:%SZ'. This format specifically includes the seconds.\r\nGrant the least possible privileges with the SAS. A security best practice is to provide a user with the\r\nminimum required privileges to the fewest possible resources. Use a read-only SAS when possible. If a\r\nuser needs only read access to a single object, then grant them read access to that single object, and not\r\nread/write/delete access to all objects. This also helps lessen the damage if a SAS is compromised because\r\nthe SAS has less power in the hands of an attacker.\r\nThere is no direct way to identify which clients have accessed a resource. However, you can use the unique\r\nfields in the SAS, the signed IP ( sip ), signed start ( st ), and signed expiry ( se ) fields, to track access.\r\nFor example, you can generate a SAS token with a unique expiry time that you can then correlate with the\r\nclient to whom it was issued.\r\nUnderstand that your account will be billed for any usage, including via a SAS. If you provide write\r\naccess to a blob, a user may choose to upload a 200 GB blob. If you've given them read access as well,\r\nthey may choose to download it 10 times, incurring 2 TB in egress costs for you. Again, provide limited\r\npermissions to help mitigate the potential actions of malicious users. Use short-lived SAS to reduce this\r\nthreat (but be mindful of clock skew on the end time).\r\nValidate data written using a SAS. When a client application writes data to your storage account, keep in\r\nmind that there can be problems with that data. If you plan to validate data, perform that validation after the\r\ndata is written and before it is used by your application. This practice also protects against corrupt or\r\nmalicious data being written to your account, either by a user who properly acquired the SAS, or by a user\r\nexploiting a leaked SAS.\r\nKnow when not to use a SAS. Sometimes the risks associated with a particular operation against your\r\nstorage account outweigh the benefits of using a SAS. For such operations, create a middle-tier service that\r\nwrites to your storage account after performing business rule validation, authentication, and auditing. Also,\r\nsometimes it's simpler to manage access in other ways. For example, if you want to make all blobs in a\r\ncontainer publicly readable, you can make the container Public, rather than providing a SAS to every client\r\nfor access.\r\nUse Azure Monitor and Azure Storage logs to monitor your application. Authorization failures can\r\noccur because of an outage in your SAS provider service. They can also occur from an inadvertent removal\r\nof a stored access policy. You can use Azure Monitor and storage analytics logging to observe any spike in\r\nthese types of authorization failures. For more information, see Azure Storage metrics in Azure Monitor\r\nand Azure Storage Analytics logging.\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 6 of 8\n\nConfigure a SAS expiration policy for the storage account. Best practices recommend that you limit the\r\ninterval for a SAS in case it is compromised. By setting a SAS expiration policy for your storage accounts,\r\nyou can provide a recommended upper expiration limit when a user creates a service SAS or an account\r\nSAS. For more information, see Create an expiration policy for shared access signatures.\r\nNote\r\nStorage doesn't track the number of shared access signatures that have been generated for a storage account, and\r\nno API can provide this detail. If you need to know the number of shared access signatures that have been\r\ngenerated for a storage account, you must track the number manually.\r\nGet started with SAS\r\nTo get started with shared access signatures, see the following articles for each SAS type.\r\nUser delegation SAS\r\nCreate a user delegation SAS for a container or blob with PowerShell\r\nCreate a user delegation SAS for a container or blob with the Azure CLI\r\nCreate a user delegation SAS for a container or blob with .NET\r\nCreate a user delegation SAS for a container or blob with Python\r\nCreate a user delegation SAS for a container or blob with JavaScript\r\nCreate a user delegation SAS for a container or blob with Java\r\nService SAS\r\nCreate a service SAS for a container or blob with .NET\r\nCreate a service SAS for a container or blob with Python\r\nCreate a service SAS for a container or blob with JavaScript\r\nCreate a service SAS for a container or blob with Java\r\nAccount SAS\r\nCreate an account SAS with .NET\r\nCreate an account SAS with Python\r\nCreate an account SAS with JavaScript\r\nCreate an account SAS with Java\r\nNext steps\r\nDelegate access with a shared access signature (REST API)\r\nCreate a user delegation SAS (REST API)\r\nCreate a service SAS (REST API)\r\nCreate an account SAS (REST API)\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 7 of 8\n\nSource: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nhttps://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview"
	],
	"report_names": [
		"storage-sas-overview"
	],
	"threat_actors": [],
	"ts_created_at": 1775434892,
	"ts_updated_at": 1775791235,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/1499c6aed5d278ebd6f1b2c832e1580aab97fe04.pdf",
		"text": "https://archive.orkl.eu/1499c6aed5d278ebd6f1b2c832e1580aab97fe04.txt",
		"img": "https://archive.orkl.eu/1499c6aed5d278ebd6f1b2c832e1580aab97fe04.jpg"
	}
}