Protect SolidStart server actions with current sessions

A SolidStart server function can access backend resources without exposing them in the browser bundle. That execution location does not establish who may call the function or which records they may change. Private queries and actions still need a current session check followed by authorization for the requested operation.

The Own Auth SolidStart guide mounts the package's HTTP handler and protects an application API route. The same ownership rule applies when application data is loaded or changed through a server function: Own Auth verifies the session, and the application decides whether that user may operate on its own records.

Keep server execution and user permission separate

SolidStart uses the "use server" directive for functions that execute on the backend. Its router supports queries for data loading and actions for mutations. These mechanisms make server work available to the application's interface. They do not turn a user supplied record ID into proof of ownership.

Consider an action that renames a project. The browser can submit the project ID and proposed name, but it must not choose the acting user ID or role. The action derives the actor from the current verified session, loads the requested project's saved owner or organisation, and checks whether that actor can rename it. Only then should it save the new name.

Read the session for the current request

Use the current request supplied by the framework's server context. The Own Auth HTTP utilities include readSessionToken for reading the package's session transport from a Web Request. Pass the resulting token to auth.getCurrentSession before using its user ID for application data access. An absent or invalid session must stop the private operation.

Do not keep one user's request, session token, or current user in a module variable shared by later requests. The auth service instance can be reused according to the runtime's lifecycle, but the requester changes. A module that remembers the last successful user creates a connection between unrelated requests that the authentication package never intended.

Authorize the saved record

A submitted organisation ID is a requested destination. It is not evidence of membership. Where a project already belongs to an organisation, derive that organisation from the saved project and evaluate the current user's permission there. Otherwise a client can combine an accessible tenant ID with an inaccessible project ID and rely on the server checking only one of them.

Keep permissions specific to the action. Reading a project, changing its name, transferring ownership, and deleting it are different operations. A user who may update content should not automatically be able to change the owner field. Select the fields the action accepts rather than spreading all submitted form values into an application database update.

Recheck after the page has loaded

A user can open a page while authorized and submit an action after their session expires. An owner can remove a membership while a settings tab remains open. The server action must evaluate current access when it runs. The earlier page render and the continued visibility of a button do not establish permission at submission time.

This also applies when a query has supplied the initial data for a form. The action should not trust the query's old result as its final authorization decision. Reuse a shared authorization helper if that keeps the rule consistent, but execute the rule for the action's own request and the current saved record before performing the mutation.

Return a response intended for the client

Own Auth's direct session lookup returns internal user and session records. Select the safe fields the interface needs, such as user ID, email, name, and image URL. Do not return the complete records from a server function merely because its code executes on the backend. Its result can still be serialized and delivered to the browser.

For the project rename example, the response can contain the saved project ID and visible name. It does not need the database connection, the authentication record, or the request's token. A narrow response makes the operation's result clear and avoids carrying credentials or unrelated private fields into router state and client caches.

Keep authentication operations in Own Auth

The package HTTP handler already owns sign up, sign in, session lookup, recovery, and configured provider callbacks. Do not duplicate those authentication operations as ad hoc SolidStart actions just because application mutations use actions. Keep one owner for cookies, verification, rate limits, and authentication errors.

Use SolidStart actions for the application's own work, with a verified actor at the start of each protected operation. A removed member must fail the next protected mutation even if the page remains open. Continue with the SolidStart integration for the handler setup and the organisation guide for permission checks that refer to the saved tenant.