Requests to charts failing with 403 error for publically accessable url only

[user1500177]

I am running a single Apache Superset pod in a Kubernetes cluster.The exact same codebase and pod work flawlessly across 3 separate private/VPN links. Users can view, load, and interact with everything over the VPN.However, when using the Public URL, everything works fine until the charts try to load. The moment chart data is requested, the upstream firewall (Azure Front Door WAF) blocks the request completely.

the error i am getting :

<style type='text/css'> body { font-family: Arial; margin-left: 40px; }

    img {
        border: 0 none;
    }

    #content {
        margin-left: auto;
        margin-right: auto
    }

    #message h1 {
        font-size: 24px;
        font-weight: normal;
        color: #000000;
        margin: 34px 0px 0px 0px
    }

    #message h2 {
        font-size: 20px;
        font-weight: normal;
        color: #000000;
        margin: 34px 0px 0px 0px
    }

    #message p {
        font-size: 16px;
        color: #000000;
        margin: 8px 0px 0px 0px
    }

    #message hr {
        margin: 15px 0px
    }

    #errorref {
        font-size: 11px;
        color: #737373;
        margin-top: 41px
    }
</style>
<title>Service unavailable</title>

The request is blocked.

20260609T050402Z-17ffbf94dd9sbhhbhC1CH1nqrg0000000cp000000000wdau

where as it worth mentioning that same issues doesnt occur with the other urls , the issue is with only the publically accceble one , what could be the causes ?

[user1500177]

@dosu could you help me with this issue what could be the reason for this ??

[dosubot[bot]]

This is almost certainly your Azure Front Door WAF blocking Superset's chart data API requests — not a Superset issue itself. The key evidence: the same pod works over VPN but fails on the public URL, meaning the WAF is pattern-matching on the request content before it reaches Superset.

Why this happens: When Superset charts load, they make POST requests to endpoints like /api/v1/chart/data with JSON payloads that contain SQL-like patterns (e.g., SELECT, WHERE, LIMIT clauses). Azure Front Door's managed WAF rulesets (especially SQL injection detection rules) commonly flag these as malicious and return a 403 block page — exactly what you're seeing [1].

How to fix it:

1. Check Azure Front Door WAF logs — In the Azure portal, go to your Front Door → WAF policy → Monitoring/Logs. Look for blocked requests and identify which specific rule IDs are triggering (likely SQL injection rules like 942xxx from the OWASP CRS ruleset).

2. Exclude Superset API paths from offending WAF rules — Once you identify the triggering rules, create exclusions for these paths:

   • /api/v1/chart/data
   • /api/v1/sqllab/execute/
   • /api/v1/database/*/validate_sql/

   You can either disable specific rules for these paths or switch matching rules from "Block" to "Log" mode.

3. Alternative: Use a custom rule with lower priority to explicitly allow requests to Superset API paths before the managed ruleset evaluates them.

This same pattern has been reported by other Superset users with different WAFs (Signal-Sciences/Fastly), and the resolution was always adjusting WAF rules to exclude Superset's API endpoints from SQL injection inspection [2].

The reason it works over VPN is that those connections bypass the Azure Front Door WAF entirely and hit the pod directly (or through a different ingress path without WAF inspection).

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.