Azure Front Door Standard Client-Side Desync protection

Question

Hello ,

I’m seeking clarification and guidance regarding a Client-Side Desync (CSD) vulnerability reported by an automated security scanner (BurpSuite) against a web endpoint that is fronted by Azure Front Door and backed exclusively by an Azure Storage Account configured as a Static Website.

- Context

Frontend: Azure Front Door (standard configuration)

Backend: Azure Storage Account Static Website

No application server or custom code behind — only static files (HTML, CSS, JS)

Endpoints: Only supports GET and HEAD requests (as documented for static websites)

No support for POST, PUT, or any other HTTP verbs

- Vulnerability Report Summary

The automated scan flagged the endpoint as vulnerable to Client-Side Desync with high severity.

Report Details:

Vulnerability: Client-Side Desync (CSD)

Description: The server allegedly failed to handle Content-Length properly in a POST request, causing the connection to remain open and misinterpret subsequent requests (potential request smuggling / desync attack).

Test behavior: The scanner sends a malformed POST request containing a second HTTP request in the body.

Expected issue: The server should reject the request or close the connection; otherwise, the connection could be reused for a malicious request.

Observed behavior:

When a malformed POST request is sent, the server responds with a 302 redirect (as it does for normal requests).

In other test cases, the server returns 400 Bad Request and closes the connection.


💡 My Analysis / Hypothesis

Based on my understanding:

Azure Storage Static Websites only support GET and HEAD requests.

Any other HTTP verb (like POST) is either ignored or rejected before being passed to the backend.

The Azure Front Door layer may handle malformed requests gracefully (e.g., via a redirect), but since no POST logic exists downstream, no actual desync or smuggling risk should exist.

The behavior described by the scanner seems consistent with a false positive, as the backend is stateless and does not maintain HTTP connections for dynamic processing.



So i was wondering:

Can Azure Front Door + Azure Storage Static Website setups be genuinely affected by Client-Side Desync attacks, given that:

The backend only supports GET and HEAD

There’s no stateful connection reuse on the backend

Requests are terminated at Azure Front Door?

Is this type of vulnerability report a known false positive for static website scenarios?

Are there recommended configurations or headers (e.g., Connection: close, enforcing HTTP/2) to explicitly prevent scanners from flagging such findings?

Is there any scenario where Azure Front Door would proxy a malformed POST with a Content-Length mismatch to a static storage backend in a way that could cause desynchronization?


Additional Notes that are important:

- The site does not expose APIs or dynamic endpoints.

- No custom backend code.

- The scan only shows this issue for the root / path.


I’d like to confirm whether this Client-Side Desync report is a false positive in this context, and if any additional security hardening or configuration is required on Azure Front Door or the storage account to suppress or address such reports.

Thank you for your assistance!

Answer 1

Hello @CodeAutoEngineer,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand your question about the Client-Side Desync (CSD) Reported. Thank you for providing the detailed background and analysis of the CSD findings. After reviewing your Azure Front Door and Azure Storage Static Website configuration, we have determined that this is a false positive and not an exploitable vulnerability.

No Actual Desync Risk

1. Azure Storage Static Websites support only GET and HEAD requests. Any POST, PUT, or other HTTP methods will be rejected with a 405 (Method Not Allowed) or 400 (Bad Request) response before body parsing or persistent connection handling occurs.
2. Azure Front Door ends client connections at the edge and manages malformed requests by returning 302 or 400 responses as appropriate.
3. Desync or request smuggling attacks rely on stateful backend connections and incomplete HTTP parsing, which are not present in your configuration.

Known False Positive Automated scanners such as Burp Suite may flag static sites that reject POST requests as “CSD” because of their general detection methods. This is recognized as a known false positive when using Front Door with Azure Storage static website setups

Next Steps

1. Indicate this as a false positive in your vulnerability management report.
2. You may choose to set up Burp Suite to exclude static paths from CSD scans.
3. No further configuration changes are needed for Azure Front Door or Storage

Kindly let us know if the above helps or you need further assistance on this issue.

Please do not forget to "Accept the answer” and “up-vote it” wherever the information provided helps you, this can be beneficial to other community members__.__ It would be greatly appreciated and helpful to others.