[Security] Backend-driven RLS Filters Not Applied to Dashboard Filters and Reset After 30 Minutes

[Gyan-Chiraniya]

Bug description

Bug: RLS Filter Not Applied to Dashboard Filter Section and Resets After 30 Minutes

Description

1. Row Level Security (RLS) filters are not being applied to the dashboard filter section, potentially exposing restricted data.
2. Additionally, RLS filters (which are backend-driven, not static) are being reset after approximately 30 minutes of dashboard inactivity, causing potential data exposure.

Expected Behavior

1. RLS filters should be consistently applied to:
   • All queries made through dashboard filters
   • Filter dropdown values
   • All data displayed in filter components
2. Backend-driven RLS filters should persist regardless of dashboard activity time.

Actual Behavior

1. RLS filters are being ignored in the dashboard filter section.
2. After ~30 minutes of dashboard inactivity, the RLS filters are reset, allowing users to see and filter by values they shouldn't have access to.

How to Reproduce

1. Set up backend-driven RLS filters for a specific role/user.
2. Create a dashboard with filters that could be affected by the RLS rules.
3. Log in as a user with that role.
4. Observe that:
   • The filter section shows values that should be restricted by RLS.
   • After 30 minutes of inactivity, the RLS filters are no longer applied.

Additional Context

• The RLS filters are backend-driven (not static).
• This issue affects all filter types in the dashboard.
• No error messages are shown when the RLS filters reset.
• The 30-minute timeout suggests a possible session or cache expiration issue.

Impact

This is a critical security issue as it can lead to unauthorized data access when:

1. Users can see filter values they shouldn't have access to.
2. After the timeout period, all RLS restrictions are lifted.

Suggested Priority

High - Security issue with data exposure risk.

Screenshots/recordings

No response

Superset version

master / latest-dev

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[dosubot]

Hi @Gyan-Chiraniya! I'm Dosu and I’m helping the superset team.

I couldn't find any existing tickets or recent pull requests that directly address backend-driven RLS filters not being applied to dashboard filters or their reset after 30 minutes. The default Superset configuration sets dashboard filter state cache to 90 days and session cookies to one week, so a 30-minute timeout is not standard and may be due to custom session or cache settings, or an external proxy/session policy in your environment. RLS enforcement is handled in backend logic and is tightly coupled to session management—if the session or cache expires, RLS may not be enforced, which can expose data you intend to restrict.

There are known issues where RLS can be bypassed in certain flows (like creating charts directly from SQL Lab without saving as a dataset), but nothing specifically about dashboard filter persistence or a 30-minute reset window in the main branch or recent PRs (example).

To mitigate, double-check your session and cache timeout settings in your Superset config and any reverse proxies or authentication layers in your deployment. Also, ensure that all dashboard filter queries and dropdowns are routed through code paths that enforce RLS. If you have custom session management, look for any 30-minute expiration policies. If the problem persists, it may be a new bug or an edge case in your deployment.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}