WeWeb Security Guide: XSS, API Protection, and Frontend Risks
WeWeb apps face frontend security challenges including XSS vulnerabilities, exposed API keys, and CSP limitations. Learn how to secure your WeWeb application.
By Daniel A · Kraftwire Software
· 9 min readWeWeb is a powerful no-code frontend builder, often paired with backends like Xano or Supabase. But as a frontend-first platform, it introduces unique security challenges that backend-focused security guides do not cover.
Understanding these challenges is important because WeWeb apps handle user interactions, display sensitive data, and make API calls, all from the browser. Every decision you make about how data flows through your WeWeb app has security implications.
WeWeb's Core Security Challenge
The CSP Problem
WeWeb requires `unsafe-eval` and `unsafe-inline` in its Content Security Policy (CSP) to function. This is a fundamental limitation. These directives are exactly what CSP is designed to prevent, because they allow arbitrary JavaScript execution in the browser.
What does this mean in practice? Content Security Policy is one of the strongest defenses against Cross-Site Scripting (XSS) attacks. It tells the browser which scripts are allowed to run on your page. When you have to set `unsafe-eval` and `unsafe-inline`, you are essentially telling the browser to allow any script to run, which defeats the purpose of having a CSP in the first place.
This does not mean WeWeb apps are inherently insecure. It means you need to be more careful about other layers of protection, because one of the standard safety nets has holes in it.
Top WeWeb Security Risks
1. Cross-Site Scripting (XSS)
Because WeWeb requires relaxed CSP directives, XSS attacks are a higher risk than in traditional frameworks. Here is how this plays out:
**Custom HTML elements** in WeWeb can execute arbitrary JavaScript. If you use a custom HTML element to display content that includes user input, you are creating a direct path for XSS attacks.
**User-generated content** displayed without sanitization becomes an attack vector. If your app shows comments, reviews, profile descriptions, or any text that users can edit, and you display it without cleaning it first, an attacker can inject scripts that run in other users' browsers.
**Third-party scripts** added via the WeWeb editor run with full page access. Every script you add to your app has the ability to read cookies, access local storage, make API calls, and interact with the DOM. Be selective about which third-party services you integrate.
**Why XSS is particularly dangerous in WeWeb apps:** Because the CSP cannot block inline scripts, a successful XSS attack gives the attacker full access to the user's session. They can steal authentication tokens, make API calls as the user, redirect them to phishing pages, or modify what the user sees on screen.
**How to reduce your XSS risk:**
Never use custom HTML elements to render user-generated content
Sanitize all user input on the backend before storing it in the database
Use text-only display modes wherever possible
Audit every third-party script in your WeWeb project and remove any that you do not actively use
Implement additional XSS protections on your backend API
2. Exposed API Keys and Secrets
WeWeb Collections make API calls directly from the browser. This is how the platform works. You configure a Collection to call an API endpoint, and that call happens from the user's browser. This means any API key used in a Collection configuration is visible in browser DevTools.
**What we commonly find exposed in WeWeb apps:**
**Backend API keys** like Xano API tokens or Supabase service role keys visible in network request headers
**Third-party API keys** for services like Stripe, SendGrid, or OpenAI embedded in Collection configurations
**Authentication tokens** stored in browser-accessible locations like local storage or cookies without the httpOnly flag
**The impact of exposed keys depends on the service:**
A leaked Stripe secret key allows an attacker to issue refunds, create charges, and access all customer data
A leaked Supabase service role key bypasses all Row-Level Security policies, giving full database access
A leaked email service key enables sending phishing emails from your verified domain
**How to protect your keys:**
Never put secret API keys directly in WeWeb Collections
Use your backend (Xano, Supabase Edge Functions) to proxy all third-party API calls
Store sensitive keys on the server side only
Use only publishable or anon keys in the frontend
Regularly check your browser's Network tab to see what is being sent in requests
3. Missing Request Headers
WeWeb's Collection system historically lacked the ability to set custom headers on requests. While this has improved, the legacy of this limitation means many WeWeb apps were built with workarounds that are less secure:
Backend endpoints had to be left "public" because the frontend could not send authentication tokens properly
CORS became the only protection layer, which is not sufficient on its own
Some builders used query string parameters to pass tokens, which get logged in server logs and browser history
**Current best practice:** Use WeWeb's header configuration to send JWT tokens in the Authorization header for every API call. If your backend is Xano, make sure every API group has authentication enabled and expects a valid JWT.
4. Client-Side Data Filtering
A common WeWeb pattern is fetching all data from the backend and filtering it client-side using WeWeb's built-in filter features. This is convenient for building dynamic interfaces, but it creates a significant security gap.
**The problem:** When you fetch all data and filter on the frontend, the complete dataset travels over the network and is available in the browser. Even if the UI only shows filtered results, a user can open DevTools, look at the Network tab, and see everything that was returned by the API.
**Example scenario:** You have an app that shows each user their own orders. If your API returns all orders and your WeWeb app filters by the logged-in user, then every user can see every other user's orders by inspecting the network response. The visual filter hides the data from the UI but not from the browser.
**How to fix it:**
Move all data filtering to your backend API
Return only the data the authenticated user is authorized to see
Use query parameters to request specific data subsets
Never rely on WeWeb's frontend filters for access control
Always test by checking what your API actually returns, not just what the UI displays
5. Insecure Data Binding and Formulas
WeWeb formulas and data bindings can inadvertently expose sensitive information:
Binding sensitive data to hidden elements still includes it in the page DOM
Formula results that include user data from other records may be visible in the debugger
Conditional visibility does not remove data from the page, it only hides it visually
**How to fix it:** Only bind data that the current user is authorized to see. If your backend returns sensitive fields that should not be shown, do not just hide them in WeWeb. Remove them from the API response entirely.
How to Secure Your WeWeb App
Step 1: Never Put Secrets in Collections
Use your backend (Xano, Supabase) to proxy all third-party API calls:
**Wrong**: WeWeb Collection calls Stripe API directly with API key in the request header
**Right**: WeWeb Collection calls your backend endpoint, which then calls Stripe using keys stored server-side
This single change eliminates the most dangerous class of vulnerability in WeWeb apps.
Step 2: Enforce Backend Authentication
Every API endpoint your WeWeb app calls must validate the user:
Use JWT tokens from your auth provider
Validate tokens server-side on every request, not just on login
Never trust client-side user IDs or roles
Return only the data the authenticated user is allowed to see
Step 3: Sanitize User Content
If your app displays user-generated content:
Sanitize HTML on the backend before storing it in the database
Use text-only display modes where possible
Never use WeWeb's custom HTML element to render user-submitted content
Implement server-side content validation that strips script tags and event handlers
Step 4: Implement Server-Side Filtering
Move all data filtering to your backend API
Use API parameters to request only the data needed
Return only the records the authenticated user should see
Never rely on WeWeb's frontend filters for access control
Test by inspecting network responses, not just the UI
Step 5: Audit Third-Party Scripts
Review every third-party script in your WeWeb project:
Remove analytics or tracking scripts you no longer use
Verify that each script comes from a trusted source
Understand what data each script has access to
Consider the impact if any of these scripts were compromised
Step 6: Scan Your Deployed App
Use [SimplyScan](https://simplyscan.io) to verify:
No API keys are exposed in network requests
Security headers are properly configured (accounting for WeWeb's CSP limitations)
No sensitive data leaks through public endpoints
Authentication is enforced correctly on all API calls
WeWeb + Supabase: Special Considerations
If you are using WeWeb with Supabase:
**Never expose the service role key** in WeWeb. Use only the anon key in your frontend configuration.
**Enable RLS on every table**. The anon key can access anything that RLS policies allow, so your policies are your main line of defense.
**Use Supabase Auth** for user authentication rather than building custom auth solutions. It handles token refresh, session management, and security headers correctly.
**Test as a logged-out user** to verify that your RLS policies actually block unauthorized access.
**Use Supabase Edge Functions** for any operation that requires the service role key, like admin operations or third-party API calls.
Key Takeaways
WeWeb's relaxed CSP makes XSS a higher risk than in traditional frameworks, so you need to be extra careful about how you handle user-generated content. Never put API secrets in WeWeb Collections. Always proxy third-party calls through your backend.
Client-side filtering looks like it works, but it is not security. Always enforce access control on the backend and return only the data each user is authorized to see.
Pair WeWeb with a properly secured backend (Xano with authentication enabled, or Supabase with RLS policies) and scan your deployed app with [SimplyScan](https://simplyscan.io) to catch exposed secrets and misconfigurations.
Related Guides
[No-Code Platform Security Guide](/blog/nocode-platform-security)
[Xano Security Guide](/blog/xano-security-guide)
[Bubble Security Guide](/blog/bubble-security-guide)
[FlutterFlow Security Guide](/blog/flutterflow-security-guide)
[Supabase Security Checklist](/blog/supabase-security-checklist)
[XSS Prevention Guide](/blog/xss-prevention-guide)