WeWeb Security Guide: XSS, API Protection, and Frontend Risks

Quick answer: WeWeb requires unsafe-eval and unsafe-inline in its Content Security Policy, making XSS a higher risk than in traditional frameworks. Secure your app by proxying API calls through a backend like Xano or Supabase, keeping secret keys out of Collections, and enforcing all data filtering on the server side.

By Daniel A · Kraftwire Software

The Direct Answer: Is WeWeb Secure?

WeWeb is secure for production use only if you enforce a strict "Backend-First" security model. Because WeWeb requires unsafe-eval and unsafe-inline in its Content Security Policy (CSP) to function, it lacks the standard browser-level safety net against Cross-Site Scripting (XSS). To protect a WeWeb app, you must never store secret API keys in Collections, you must proxy all third-party requests through a backend like Xano or Supabase Edge Functions, and you must perform all data filtering on the server rather than in the browser.

Understanding WeWeb's Core Security Challenge

The CSP Limitation

The most significant architectural risk in WeWeb is its reliance on relaxed security headers. A standard Content Security Policy (CSP) is a security layer that helps detect and mitigate certain types of attacks, including XSS and data injection. However, WeWeb’s runtime requires unsafe-eval and unsafe-inline to execute its dynamic logic and formulas.

This effectively disables the browser's ability to distinguish between legitimate application code and malicious scripts injected by an attacker. If an attacker manages to inject a script into your page (e.g., through a user profile field), the browser will execute it without hesitation.

It is important to note that WeWeb is evolving. While these features improve the developer experience, the fundamental frontend risk of unsafe-eval remains a factor for the client-side runtime.

Top 5 WeWeb Security Risks and Mitigations

1. Cross-Site Scripting (XSS) Vulnerabilities

Because the CSP cannot block inline scripts, XSS is the primary threat to WeWeb applications.

• Custom HTML Elements: WeWeb allows you to drop in custom HTML. If you bind this element to a variable containing user-generated content (like a comment or a username) without sanitization, you have created a stored XSS vulnerability.
• Third-Party Script Injection: Any script added via the "Custom Code" section of your project settings runs with full access to the user's session. If a third-party analytics provider is compromised, your users' data is at risk.

How to mitigate:

• Use the XSS Prevention Guide to implement backend sanitization.
• Never use the "Custom HTML" element to display data that originated from a user.
• Use the SimplyScan CSP Evaluator to see exactly what your current policy allows.

2. Exposed API Keys in Collections

A common mistake for "vibe-coders" and no-code builders is placing secret API keys (like OpenAI, Stripe, or SendGrid) directly into the WeWeb Collection configuration.

The Reality: WeWeb Collections execute in the user's browser. When the app fetches data, it makes a network request from the user's IP. Any header or query parameter you include in that Collection is visible to anyone who opens the browser's "Inspect Element" Network tab.

How to mitigate:

• Proxy everything: If you need to call OpenAI, do not call it from WeWeb. Call a Xano API or a Supabase Edge Function, and have *that* server-side function call OpenAI using a secret key stored in an environment variable.
• Check your app now with our Secret Scanner.

3. Client-Side Data Filtering (The "Visual Security" Trap)

WeWeb makes it very easy to fetch a list of records and then apply a "Filter" in the UI to show only the records belonging to the current user.

The Danger: This is not security; it is a visual preference. The API request still returns the *entire* list of records to the browser. The user's browser receives all the data, and WeWeb simply hides the rows that don't match the filter. An attacker can view the full JSON response in the Network tab and see every record in your database.

How to mitigate:

• Always filter data on the backend. Your API should require an authentication token and return *only* the records that the specific user is authorized to see.
• Read our Broken Access Control Checklist for more on this.

4. Insecure Supabase Integration

Many WeWeb users pair the platform with Supabase. The most common risk here is the exposure of the service_role key.

• The Anon Key: Safe to use in WeWeb. It respects Row-Level Security (RLS).
• The Service Role Key: Never use this in WeWeb. It bypasses all RLS and gives full admin access to your database.

If you are using Supabase, you must ensure RLS policies are active on every single table. Without RLS, the anon key is just as dangerous as a leaked admin key.

5. Lack of Security Headers

Beyond the CSP, many WeWeb apps fail to implement basic security headers like X-Frame-Options (to prevent clickjacking) or Strict-Transport-Security (HSTS). While WeWeb handles some of this on their hosted platform, custom domains and proxied setups often miss these.

How to mitigate:

• Run your URL through our Security Headers Tool to get a grade from A to F.
• Ensure your backend (Xano/Supabase) also sends correct CORS configurations.

The Ultimate Vibe Coding Security Checklist: Ship WeWeb Apps Safely

If you are building with AI tools like Cursor or Windsurf and deploying to WeWeb, use this checklist before you go live:

• No Secrets in Frontend: Search your entire WeWeb project for strings starting with sk-, key-, or secret. Move these to your backend environment variables.
• Server-Side Auth: Ensure every Collection requires a Bearer token. Use the JWT Debugger to verify your tokens aren't leaking sensitive claims.
• Sanitize User Input: If your app accepts text input, ensure your backend strips <script> tags before saving to the database.
• RLS Verification: If using Supabase, try to access your API URL in an Incognito window without a token. It should return an empty array or an error, never data.
• Audit Third-Party Scripts: Remove any old Google Tag Manager or tracking scripts that aren't strictly necessary.
• Monitor Uptime: Use Uptime Monitoring to ensure your backend isn't failing, which can sometimes cause frontend "fail-open" states where security checks are bypassed.

How SimplyScan Protects WeWeb Developers

SimplyScan is specifically designed for the "vibe-coding" era. We understand that when you build with AI, you move fast · and moving fast leads to security oversights.

Our WeWeb Security Scanner performs a comprehensive audit in ~30 seconds:

• Exposed Key Detection: We scan your frontend bundles and network patterns for leaked API keys.
• Architecture Audit: We identify if you are performing dangerous client-side filtering.
• Compliance Signals: We check for GDPR/compliance signals and SPF/DKIM/DMARC health for your domain.
• AEO Visibility: We check if your WeWeb SPA is actually indexable by AI agents like Perplexity and ChatGPT (see our AEO Guide).

For WeWeb users, this almost always refers to the "Client-Side Filtering" risk mentioned above.

Advanced: Securing WeWeb with Xano

Xano is the most popular backend for WeWeb. To secure this pairing:

• Enable JWE/JWT: Use Xano’s built-in Auth and ensure every API group has the "Authentication" toggle turned ON.
• Use API Lambdas for Secrets: If you need to integrate with a third-party service, create a Xano function that handles the API key and only returns the necessary data to WeWeb.
• Rate Limiting: AI-built apps are often targets for scraping. Enable rate limiting in Xano to prevent attackers from draining your database or your OpenAI credits.

Conclusion: Security is a Process, Not a Setting

WeWeb is a world-class frontend builder, but its flexibility requires a disciplined approach to security. By moving your logic and secrets to the backend, you compensate for the platform's CSP limitations and build an app that can scale safely.

Don't guess if your app is secure. Run a free scan at SimplyScan.io today. We provide a verified security badge for your footer once you've cleared high-severity risks, proving to your users that their data is handled with care.

Related Guides

• Xano Security Guide
• Supabase Security Checklist
• Windsurf Security Risks & Mitigation
• AI API Security Best Practices
• Vibe Coding Security Checklist

FAQ

Is WeWeb secure enough for enterprise production apps?

Yes, provided you follow a "stateless frontend" model. WeWeb is used by many large organizations, but they treat the frontend as a pure presentation layer. All sensitive logic, secret management, and data authorization must happen on a secure backend like Xano, Supabase, or a custom Node.js/Python server. Never rely on the frontend to "hide" data that the user shouldn't see.

Why can't I just fix the CSP in WeWeb settings?

You cannot tighten the CSP directives unsafe-eval and unsafe-inline because WeWeb’s core engine uses them to interpret the formulas and logic you build in the editor. If you were to block these, the app would stop functioning. This is a trade-off for the platform's ease of use, making server-side sanitization and secret management your primary lines of defense.

Can hackers see my OpenAI or Stripe keys in WeWeb?

If you put those keys in the "Headers" section of a WeWeb Collection, then yes · they are public. Anyone can open the browser's developer tools and see the key in plain text. To prevent this, you must use a backend "proxy" function. Your WeWeb app calls your backend, and your backend calls Stripe/OpenAI using a hidden secret key.

Does WeWeb's built-in filtering protect my data?

No. WeWeb's frontend filters are for user experience, not security. If your API returns 1,000 rows and you filter it to show 10, the browser still receives all 1,000 rows. An attacker can see all 1,000 rows by looking at the JSON response in the Network tab. Always filter your data at the database or API level.

Which Supabase key is safe to use in the WeWeb editor?

Only the anon (anonymous) key is safe for frontend use. The service_role key is a "super admin" key that bypasses all security rules and must never be placed in WeWeb. Even with the anon key, you must enable Row-Level Security (RLS) on every table in Supabase to ensure users can only access their own data.

How do I perform a security audit on my WeWeb app?

Start by manually checking the Network tab in your browser to see if any sensitive data or keys are being sent. Then, use an automated tool like SimplyScan to check for common misconfigurations, exposed environment variables, and missing security headers. SimplyScan provides a comprehensive report in 30 seconds that covers security, speed, and AEO.