WeWeb Security: Frontend Risks, Backend Protection, and GDPR

Open your published WeWeb app in Chrome. Press F12 to open DevTools. Go to the Network tab and reload the page. You will see every API request your app makes — including the Supabase URL, the anon key in request headers, and the data returned from your database. Go to Application tab → Local Storage — you will see the Supabase auth session token (JWT). Go to Sources tab — you can see WeWeb's compiled JavaScript, and if you examine it, you can find the configuration your app was built with. This is not a flaw unique to WeWeb — all SPAs work this way. What this means: (1) Your Supabase anon key IS visible — this is expected and fine because the anon key's access is controlled by RLS policies. (2) The data returned from API calls is visible — only request data you want the current user to be able to see. (3) Your backend API URL is visible — do not put secret logic in URL paths. (4) JavaScript logic is visible — do not put private keys or sensitive algorithms in WeWeb workflows. The anon key being visible is fine. The SERVICE_ROLE key being visible would bypass all RLS — never use it in WeWeb.

CRITICAL: WeWeb's REST API plugin sends all configured headers directly from the browser. If you have added a third-party API (OpenAI, Stripe, Twilio, SendGrid, a custom API) using the REST API plugin with an Authorization or API-Key header, that key is visible to anyone using your app. Open DevTools → Network tab → find requests to your third-party API → inspect the request headers. If your private API key appears there, it is exposed. The fix: never call APIs that require private keys directly from WeWeb's REST API plugin. Use a Supabase Edge Function as a server-side proxy. The Edge Function stores the private key as a Supabase Secret (Deno.env.get()) and your WeWeb app calls the Edge Function (which uses the Supabase anon key for authentication) — the private key never leaves the server. WeWeb's OpenAI plugin is an exception — it processes the key server-side through WeWeb's infrastructure, so the key is not exposed in browser requests. Always test: add the API key to the REST API plugin, open DevTools Network tab, make an API call, and check if the key appears in request headers. If it does, move the call to an Edge Function.

1// Injection point: Supabase Edge Function
2// File: supabase/functions/openai-proxy/index.ts
3// Deploy via: Supabase Dashboard → Edge Functions → Deploy
4// Then call this from WeWeb: Supabase → Invoke Edge Function
5
6import { serve } from 'https://deno.land/std@0.168.0/http/server.ts';
7
8const corsHeaders = {
9  'Access-Control-Allow-Origin': '*',
10  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
11};
12
13serve(async (req) => {
14  // Handle CORS preflight
15  if (req.method === 'OPTIONS') {
16    return new Response('ok', { headers: corsHeaders });
17  }
18
19  try {
20    const { prompt, model = 'gpt-4o-mini' } = await req.json();
21
22    // Private key lives here — never in WeWeb frontend
23    const openaiKey = Deno.env.get('OPENAI_API_KEY');
24    if (!openaiKey) throw new Error('OPENAI_API_KEY not configured');
25
26    const response = await fetch('https://api.openai.com/v1/chat/completions', {
27      method: 'POST',
28      headers: {
29        'Authorization': `Bearer ${openaiKey}`,
30        'Content-Type': 'application/json',
31      },
32      body: JSON.stringify({
33        model,
34        messages: [{ role: 'user', content: prompt }],
35        max_tokens: 500,
36      }),
37    });
38
39    const data = await response.json();
40    return new Response(JSON.stringify(data), {
41      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
42    });
43
44  } catch (error) {
45    return new Response(
46      JSON.stringify({ error: error.message }),
47      { status: 500, headers: { ...corsHeaders, 'Content-Type': 'application/json' } }
48    );
49  }
50});

OUTSIDE WEWEB — this step happens entirely in Supabase. RLS (Row Level Security) is a PostgreSQL feature that allows you to define data-access policies at the database level. When enabled on a table, every query — from any client, including direct API calls bypassing your WeWeb frontend — is checked against the policy. If the policy evaluates to false for a row, that row is not returned or modified. Enable RLS on every table that stores user or sensitive data: in Supabase Dashboard → Table Editor → select table → click 'RLS' → 'Enable Row Level Security'. When RLS is enabled with no policies, ALL operations are blocked — the table is completely locked down. Then add policies to allow authorized operations. A well-secured app has: (1) tables with no user data have no RLS needed (e.g., public product catalog), (2) tables with user data have RLS enabled + policies that check auth.uid(), (3) tables with admin-only data have RLS + role-check policies. The minimum RLS test: enable RLS on a test table, make a call from WeWeb without being logged in, confirm you get 0 rows (not an error). Then log in as a user, confirm you see only your rows. Then try as admin, confirm you see all rows.

1-- Injection point: Supabase SQL editor (run OUTSIDE WeWeb)
2-- Security audit: check which tables have RLS disabled
3-- Run this query to find tables without RLS enabled
4
5SELECT
6  schemaname,
7  tablename,
8  rowsecurity as rls_enabled,
9  CASE WHEN rowsecurity THEN 'SECURE'
10       ELSE 'WARNING: RLS DISABLED'
11  END as security_status
12FROM pg_tables
13WHERE schemaname = 'public'
14ORDER BY rowsecurity ASC, tablename;
15
16-- List all existing RLS policies:
17SELECT
18  schemaname,
19  tablename,
20  policyname,
21  cmd as operation,
22  qual as using_expression,
23  with_check as with_check_expression
24FROM pg_policies
25WHERE schemaname = 'public'
26ORDER BY tablename, cmd;
27
28-- Quick fix: enable RLS on all public tables that are missing it
29-- CAUTION: This locks down all access — add policies immediately after
30-- ALTER TABLE public.your_table ENABLE ROW LEVEL SECURITY;

WeWeb's authentication plugins (Supabase Auth, Auth0) manage JWT tokens automatically. When a user logs in, the JWT (access token) is stored in localStorage by the Supabase client SDK. This is a deliberate choice — localStorage persists across browser sessions but is accessible to JavaScript code running on the page. The security trade-off: JWTs in localStorage are vulnerable to XSS attacks (malicious JavaScript injected into the page can read localStorage). WeWeb applications benefit from Vue.js's built-in XSS protections — Vue's template compiler escapes all dynamic values by default, preventing script injection via bound text content. However, custom JavaScript in WeWeb workflows runs without Vue's protections — never use `innerHTML` with user-supplied content in Custom JavaScript actions. For CSRF: WeWeb's Supabase calls use the JWT in the Authorization header rather than cookies, making traditional CSRF attacks (which require session cookies) ineffective against API calls. Token expiry: Supabase access tokens expire after 1 hour by default. The SDK auto-refreshes using the refresh token (7-day expiry). You do not need to handle token refresh manually.

WeWeb has a built-in Privacy & Consent feature. Go to Project settings → Privacy & Consent. Two consent modes: Explicit (opt-in — users must actively accept before any tracking scripts run) and Implicit (opt-out — scripts run by default, users can opt out). Enable the privacy settings → configure which scripts require consent (analytics, marketing, essential). WeWeb's implementation is basic — for GDPR compliance in European markets or complex regulatory requirements (CCPA, LGPD), use a third-party Consent Management Platform. Recommended options: CookieYes (has a free tier, easy to integrate) or Osano. Integration: add the CookieYes script to App Settings → Custom Code → Head. Configure CookieYes to block your analytics scripts until consent is given. The GTM plugin can be configured to fire tags only after consent signals from CookieYes. One important data residency note: WeWeb's WeWeb Auth plugin stores user data on AWS infrastructure in the United States. If your users are EU-based and you use WeWeb Auth, this creates GDPR data residency concerns. Supabase Auth is hosted in your chosen region (including EU regions). Choose your auth provider accordingly.

When WeWeb calls a Supabase Edge Function via 'Supabase → Invoke Edge Function', the user's Supabase JWT is automatically included in the request. Inside the Edge Function, verify this JWT before processing the request — do not assume all callers are authenticated. Extract the Authorization header, verify it with Supabase's JWT library, and check the user's identity and roles before executing any logic. This prevents unauthenticated callers (or users with insufficient roles) from triggering server-side operations. The Edge Function has access to the Supabase service_role key via `Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')` — it can perform admin-level database operations. This is the correct place to use the service_role key (server-side only, never in WeWeb frontend).

1// Injection point: Supabase Edge Function
2// File: supabase/functions/admin-action/index.ts
3// This pattern validates the caller's JWT before performing admin operations
4
5import { serve } from 'https://deno.land/std@0.168.0/http/server.ts';
6import { createClient } from 'https://esm.sh/@supabase/supabase-js@2';
7
8const corsHeaders = {
9  'Access-Control-Allow-Origin': '*',
10  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
11};
12
13serve(async (req) => {
14  if (req.method === 'OPTIONS') {
15    return new Response('ok', { headers: corsHeaders });
16  }
17
18  try {
19    // Verify the caller's JWT
20    const authHeader = req.headers.get('Authorization');
21    if (!authHeader) {
22      return new Response(JSON.stringify({ error: 'Unauthorized' }), {
23        status: 401,
24        headers: corsHeaders,
25      });
26    }
27
28    const supabaseUrl = Deno.env.get('SUPABASE_URL')!;
29    const supabaseKey = Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!;
30    const anonKey = Deno.env.get('SUPABASE_ANON_KEY')!;
31
32    // Verify user JWT using anon client
33    const userClient = createClient(supabaseUrl, anonKey, {
34      global: { headers: { Authorization: authHeader } },
35    });
36
37    const { data: { user }, error } = await userClient.auth.getUser();
38    if (error || !user) {
39      return new Response(JSON.stringify({ error: 'Invalid token' }), {
40        status: 401, headers: corsHeaders,
41      });
42    }
43
44    // Check admin role
45    const adminClient = createClient(supabaseUrl, supabaseKey);
46    const { data: userRoles } = await adminClient
47      .from('users_roles')
48      .select('roles!inner(name)')
49      .eq('user_id', user.id);
50
51    const isAdmin = userRoles?.some(r => r.roles?.name === 'admin');
52    if (!isAdmin) {
53      return new Response(JSON.stringify({ error: 'Forbidden' }), {
54        status: 403, headers: corsHeaders,
55      });
56    }
57
58    // Perform admin operation here
59    const body = await req.json();
60    // ... your admin logic ...
61
62    return new Response(JSON.stringify({ success: true }), {
63      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
64    });
65
66  } catch (error) {
67    return new Response(JSON.stringify({ error: error.message }), {
68      status: 500, headers: corsHeaders,
69    });
70  }
71});

Before going live, run through this security checklist systematically. In WeWeb: confirm no private API keys are in the REST API plugin headers (check Network tab in DevTools). Check that all pages intended to be private have access control configured AND backend RLS. Verify that conditional rendering hiding sensitive UI does not expose the data via collections that fetch it regardless. In Supabase: run the RLS audit SQL query (from Step 3) to confirm all user-data tables have RLS enabled. Test as an unauthenticated user — try direct Supabase API calls with the anon key but no JWT. Test as a low-privilege user — confirm they cannot read admin data. In your app: confirm logout actually clears the session and redirects correctly. Check that error messages do not leak sensitive information (e.g., 'User not found' vs 'Invalid credentials'). Check that form inputs that accept user content are not used in innerHTML-equivalent bindings. For compliance: document what user data you collect and store, where it is stored (Supabase region), and your data retention policy. This is minimum GDPR due diligence.