Azure Table REST API / 403 (Server failed to authenticate the request. Works in Postman but not on static web page

Question

Hi all.

I have an azure static web page setup and want to communicate with my Azure Table service through REST API, which I was told would be possible.

After a while I figured out how to properly authorize my requests through the Shared Key signature. I validated this by using Postman and sending a simple GET request with the correct Date/Authorization headers, and get a 200 response.

This is what my fetch code block looks like:

     fetch('https://storagename.table.core.windows.net/Tables', {
        method: 'GET',
        mode: 'cors',
        headers: {
            'Accept': '*/*',
            'Access-Control-Allow-Origin': '*',
            'Access-Control-Allow-Methods': '*',
            'Authorization': `SharedKey storagename:${sigBase64}`,
            'Date': date.toUTCString(),
            'x-ms-version': '2019-02-02',
            'DataServiceVersion': '3.0;NetFx',
        },
        redirect: 'follow'
    }).then(function(response){
        if (response.ok){
            return response.json();
        }else{
            return Promise.reject(response);
        }
    }).then(function(data){
        console.log(data);
    })  

On my Azure Table settings under Resources, I've enabled CORS for all domains (*).

I'm a little confused as to what troubleshooting I can try next. I'm assuming there is some CORS policy or header I'm missing but the 403 return message doesn't help too much.

Does anyone have an idea of what I should look into next?

Answer 1

Hello Darren,

Thank you for reaching out to Microsoft Q&A forum.

I understand that you were having issues with Azure Storage REST API with Shared Key which was giving you 403 errors. The error message indicates that the server failed to authenticate the request, suggesting that there might be an issue with the Authorization header.

You can try troubleshooting this issue by following below checks,

• One of the major reasons why this error occurs is with the wrong SAS token, or you may give the wrong SAS parameter you have passed in your SAS-URL. refer - https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key
• The Date header is crucial for Shared Key authorization. Make sure it’s correctly set in your fetch request. Azure Storage REST API with Shared Key which was giving 403 errors also may be due to the date format which will be fixed after you 0 padded the date. Hence please check the date format for Azure Storage is mentioned here- https://learn.microsoft.com/en-us/rest/api/storageservices/formatting-datetime-values.
• You mentioned that you’ve enabled CORS for all domains (*). Confirm that the CORS settings are correctly applied in your Azure Table service and ensure that the allowed origins, methods, and headers match your fetch request. Sometimes a small typo or misconfiguration can cause issues. When making a cross-origin request, the browser sends a preflight request (HTTP OPTIONS) to check if the actual request (GET in your case) is allowed. Verify that your server responds correctly to the preflight request. It should include the necessary CORS headers (e.g., Access-Control-Allow-Origin, Access-Control-Allow-Methods, etc.). refer - https://learn.microsoft.com/en-us/azure/api-management/cors-policy, https://learn.microsoft.com/en-us/rest/api/storageservices/cross-origin-resource-sharing--cors--support-for-the-azure-storage-services, https://learn.microsoft.com/en-us/troubleshoot/azure/azure-storage/troubleshoot-storage-client-application-errors?tabs=dotnet#the-client-is-receiving-http-403-forbidden-messages
• Since you’re using Shared Key authorization, ensure that the Authorization header in your fetch request is correctly formatted and also double-check that the sigbase64 value is generated accurately based on your account key and request details.
• Verify that there are no IP-based access restrictions or firewall rules blocking requests and check if there are any other security mechanisms (such as Azure Firewall or Network Security Groups) affecting the communication.

Please let us know if you have any further queries. I’m happy to assist you further.

---

Please "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.