Company B tries three Azure options to put a WAF in front of its Blazor Server / SignalR marketplace. What happens with each?
- Attempt a, Azure Front Door (with its WAF): no support for sockets.
- Attempt b, Azure Application Gateway WAF: works only as a gateway, with no checking routines (OWASP or other), at high cost.
- Attempt c, Azure Front Door SignalR gateway: also only a gateway without checks, at moderate cost.
* Either the socket breaks, or it passes through a gateway that doesn't inspect it. *
The root of the problem is that a classic WAF inspects HTTP requests and responses one by one. A SignalR app upgrades its connection once to a WebSocket and then streams messages in both directions over that single long-lived connection. A WAF either doesn't support that upgrade, which breaks the application, or lets it through as a pass-through gateway, without applying its rule sets (such as the OWASP core rules) to the messages inside. So the options either break the marketplace or "protect" it in name only, one of them at high cost.
Cloud offerings change quickly, and the case is meant as an illustration: by now Azure Front Door does support WebSockets, but its WAF still checks only the opening handshake, not the messages afterwards. Anyone using the technology should check the current situation.
Go deeper:
Microsoft Q&A — SignalR and the WAF in Application Gateway — the Application Gateway WAF blocks WebSockets by default, and the exclusion that lets them through also skips SQL-injection checks.- Microsoft Tech Community — Protect your SignalR Service based real-time application with Application Gateway — the reference set-up of a SignalR service behind Application Gateway.
- Microsoft Learn — WebSocket on Azure Front Door — today's support, and the note that the WAF inspects only the WebSocket handshake.