Securing your application

Security isn't a single switch you flip; it's a series of layers. You need to ensure users are who they say they are (Authentication), that they can only do what they're allowed to do (Authorization), and that they only see what they're supposed to see (Privacy).

Layer 1: Authentication (Who are you?)

Authentication is the front door. It verifies a user's identity. In WeWeb, this is split between the Authentication panel in the Data & API, and workflow actions in the Interface.

1. Managing Users (Backend)

The Authentication tab in the Data & API section is where you manage your user base. Here you can:

• View all registered users.
• Manually assign Roles (like Admin or Editor) to control what they can do.
• Add authentication integrations (like Google or Github).

2. Signing Users In (Interface)

To actually let users sign up or log in, you use Workflows in the Interface tab. WeWeb provides secure, built-in actions for all standard auth flows.

Some of the actions you have available from Interface workflows include:

• Sign up with email
• Sign in with email
• Request password reset
• Sign out

Best Practice: Always use the built-in Authentication actions. Never try to "roll your own" authentication system using simple tables and variables, as this is easily hackable.

Layer 2: Authorization (What can you do?)

Just because someone is logged in doesn't mean they should be able to delete your entire database. This is where Authorization comes in.

Securing Data (Views)

When you create a View of your table, you set permissions:

• Public — Anyone can see it (good for Blog Posts).
• Authenticated — Only logged-in users (good for a generic Dashboard).
• Roles/Groups — Only "Admins" or "Editors".

Securing Logic (APIs)

As discussed in Creating Secure Logic, every API needs security settings.

Use Middleware to enforce granular rules (e.g., "User can only edit their own projects").

Layer 3: Data Privacy (What can you see?)

A common mistake is sending too much data to the Interface and "hiding" it with the Display or Conditional rendering properties.

Example of a security flaw:

1. You fetch a list of Users. The data includes Name, Email, and Salary.
2. In the Interface, you only display Name and Email.
3. The security hole: A hacker can open the browser's "Network" tab and see the raw data coming from the server, including Salary.

The Solution:

• Create specific Views that only return the columns you need. Create a Public Users view that only includes Name and Avatar, and excludes sensitive fields.

Interface "Security" (UX vs Real Security)

You will see features in the Interface tab, like Private Pages and Conditional Rendering. It is vital to understand their role.

• Private Pages — These prevent a user from navigating to a page. They are a UX feature. They do not secure the data on that page. If you have a public view or API to retrieve the data of that page, then a user can fetch it without visiting the page.
• Conditional Rendering — This prevents an element from being drawn on the screen. It does not prevent the data bound to it from being downloaded to the browser.

The Golden Rule: If data is sensitive, ensure the View or API you are using to get the data is secured and refuses to send it to unauthorized users. Never rely on the features in the Interface tab to hide it.

Security Checklist

Before you launch, run through this checklist:

• Authentication

  Users must log in to access private areas.
• Views

  Are your views restricted? Do they exclude sensitive columns?
• APIs

  Do all your APIs have needed Middleware?
• Roles

  Are Admin-only features strictly gated by Roles in the backend?
• Testing

  Have you tried to access data as a 'Logged Out' user to test your defenses?

CONGRATULATIONS

You've completed the WeWeb 101 journey! You now understand the Interface, the Backend, and how to connect them securely.

Ready to build? Check out our practical build guides: Build Guides →