Secure Server-Side Data

Introduction

This tour frames server-side security the way Wappler actually enforces it: a shared provider establishes identity, protected actions read that identity from session context, and permissions decide which server operations remain available after login.

Protect the action, not just the page

A protected page is not enough on its own. Real security happens when the server action behind the page also checks identity and permissions. That way, the API stays protected even if someone bypasses the visible page workflow.

Shared provider

One security provider supplies the session identity for the project.

Protected actions

Server actions should enforce login and permissions directly.

Session context

The action can read who is logged in and what they are allowed to do.

Protect API endpoints as first-class surfaces

Reuse the same provider across login, pages, and actions

Treat page restriction and action restriction as complementary

Identity and authorization are different checks

First the action decides whether a session exists. Then it decides whether that session has the right permission for the job. That distinction matters because a signed-in user can still be unauthorized for an admin-only action.

important: Missing login and missing permission are different failure states and should stay separate in your mental model.

Login answers who the user is

Permissions answer what that user can do

Design error handling around both checks

Common secure-action patterns

Most secure server-side data flows reduce to a few repeatable patterns.

Pattern: scope the action to the current user

When an action reads or updates user-owned data, prefer deriving the user id from session context instead of trusting a client-supplied value. That reduces accidental privilege escalation and keeps the action aligned with the authenticated session.

Read user context from the provider-backed session

Avoid trusting raw client identity fields

Use route params only after they pass permission checks

Pattern: require a permission for elevated actions

For admin screens and management APIs, combine shared login protection with a permission check. The same provider can authenticate everyone, while page or action permissions narrow who may perform sensitive operations.

Let one provider authenticate multiple roles

Apply permissions only where elevation is needed

Keep admin-only logic explicit in the action flow

Pattern: debug secure actions from the server side out

When a secure action fails, inspect provider setup, session creation, and permission mapping before changing the page. Most authentication bugs come from mismatched provider assumptions rather than from the visible form.

Wrap-up

Continue into the provider, login, or page-restriction branches from here.

Next steps

Pick the security branch you want to continue with.