ypandey-fluidata opened a new issue, #37365:
URL: https://github.com/apache/superset/issues/37365

   ### Bug description
   
   We are implementing superset-embedded-sdk within a multi-tenant application 
where the frontend is a no-code platform (Softr). The application serves data 
from a PostgreSQL warehouse with strict Row-Level Security (RLS) requirements.
   
   Current Implementation (Insecure) Currently, the client-side JS fetches a 
Guest Token by passing the user’s email directly to a backend endpoint.
   fetchGuestToken: () => 
fetch(`https://api.test.co/get-token?email=${window.logged_in_user.email}`)
   
   --This is susceptible to ID Spoofing. Since the frontend JS is public, a 
user can modify the email variable in the console to request a Guest Token 
scoped to a different tenant’s RLS rules.
   
   The Proposed "Zero-Trust" Architecture 
   We are moving to a token-based exchange to eliminate PII and spoofing. We 
would appreciate feedback from the maintainers on the security of this flow:
   
   1. Token Generation: Upon user login, our backend generates a unique, random 
App_Session_Hash (stored in Postgres, mapped to the user).
   2. Frontend Handshake: Softr passes only this hash to our Middle-man API.
   3. Backend Validation:
   - The API validates the App_Session_Hash against the DB.
   - It retrieves the associated rls_clause (e.g., client_id = 501) directly 
from Postgres.
   - Superset API Call: The API calls the Superset 
/api/v1/security/guest_token/ endpoint (Server-to-Server) using the rls_clause 
retrieved from the DB.
   - Scoped Delivery: The Guest Token is returned to the frontend.
   
   #Specific Questions for Apache Superset Devs:
   
   1. Guest Token Over-scoping: Is there a risk of "Token Hijacking" if the 
guest_token is intercepted? Does the SDK provide a way to bind the token to a 
specific client IP or browser session beyond the exp (expiration) claim?
   
   2. CSRF in Embedded Context: When the SDK performs the fetch for the 
dashboard assets using the Guest Token, how can we ensure that the 
fetchGuestToken call itself is shielded from CSRF attacks given that we cannot 
easily set custom HttpOnly cookies in a no-code frontend?
   
   3. SDK Caching: Does the embedded-sdk have a native way to handle token 
refresh before expiration without a full page reload, or should we implement a 
recursive setTimeout logic within the fetchGuestToken function?
   
   Environment:
   
   Superset Version: 6.0
   
   ### Screenshots/recordings
   
   _No response_
   
   ### Superset version
   
   master / latest-dev
   
   ### Python version
   
   3.9
   
   ### Node version
   
   16
   
   ### Browser
   
   Chrome
   
   ### Additional context
   
   _No response_
   
   ### Checklist
   
   - [x] I have searched Superset docs and Slack and didn't find a solution to 
my problem.
   - [x] I have searched the GitHub issue tracker and didn't find a similar bug 
report.
   - [x] 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.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to