Problem Statement
An HTML file stored in Azure Blob Storage was not accessible when opened as a direct link.
The following issues were encountered:
Without authentication, the blob was private and returned Authorization errors.
When accessed via a generated SAS token, the browser attempted to download the file instead of rendering it as an HTML page.
Direct access using a blob endpoint was not possible for users inside the network without special permissions.
The requirement was to make the file viewable in a browser as a web page via a shareable link while still controlling access.
The soultion is SAS tokens
After investigation, the following steps were taken to make the file accessible through a SAS token and open correctly in the browser.
Generate a SAS Token for the Blob
A Shared Access Signature (SAS) token grants time-limited and permission-scoped access to a specific blob without exposing the storage account key.
Steps (Azure Portal):
_Navigate to the Azure Storage Account in the Azure Portal.
Go to Containers → open the target container (e.g., invetoryreport).
Locate and click on the HTML file (e.g., /stockdata/invetoryreport.html).
Click Generate SAS at the top.
Configure:
Permissions: Read (r)
Start time: A few minutes earlier than the current time (to avoid clock skew issues)
Expiry time: As per requirement (e.g., 1 day or 1 week)
Allowed protocol: HTTPS
(Optional) Allowed IP addresses: Specify if restricting to certain networks
-
Click Generate SAS token and URL.
-
Copy the Blob SAS URL provided. This URL contains the file path and SAS token parameters._
Set Correct Content-Type for the Blob
By default, blobs may be served with the application/octet-stream MIME type, which forces browsers to download them. To make an HTML file render in a browser, the Content-Type must be set to text/html.
Steps (Azure Portal):
In the blob’s details page, click Properties.
Locate the Content-Type field.
Change the value to text/html
Save the changes.
Congratulations!!!! . Now you can access file directly in browser
Advantages of SAS Tokens
Granular Access Control You can grant access to specific resources (containers, blobs, queues, tables, files) without giving full account keys. Permissions can be fine-tuned (read, write, delete, list, etc.).
Time-Bound AccessTokens can expire automatically, reducing the risk of long-term exposure.
No Need to Share Account Keys Account keys give full access; a SAS token limits scope and reduces potential damage if compromised.
Temporary & Revocable You can revoke access by regenerating the storage account keys or changing stored policies.
Flexible Delivery Tokens can be passed via URLs, making them easy to use in applications, scripts, and APIs without extra authentication steps.
Disadvantages of SAS Tokens
Security Risk if Leaked Anyone with the SAS URL has the permissions until it expires — so tokens must be protected like passwords.
Difficult to Revoke Before Expiry For ad hoc SAS tokens (not tied to a stored access policy), you can’t revoke them without rotating the storage account key.
Potential for Over-Permissioning If not configured carefully, a token might allow more actions than intended.
Expiration Management Short expiry improves security but can cause operational issues if the token expires mid-process; long expiry increases risk if leaked.
Logging Limitations You can see when storage is accessed, but you can’t easily trace the identity of the person using the token — it’s just whoever has it.
💡 Best Practice:
Use stored access policies where possible — they let you revoke a SAS without touching account keys.
Always use HTTPS to prevent token sniffing.
Keep SAS lifetimes short and permissions minimal.