Are my Server Actions actually protected?
Treat a callable Server Action or route handler as an entry point that needs its own validation and permission checks. Review the server-to-client boundary, then test whether an unauthenticated user or a different account can reach protected data or mutations.
Who this is for: Next.js App Router teams shipping dashboards, AI features, subscriptions and customer portals.
STEP 01
Identify endpoints by behavior, not by folder name
A page can require login while a related mutation accepts a request without checking the caller. List the actions that change roles, export data, create checkout sessions or update account settings. For each, identify the data access function it invokes. Centralizing permission checks makes that review easier, but still requires tests at the entry point.
Try this: Pick one sensitive operation and test it without a session, with an ordinary account and with an authorized account.
STEP 02
Return only the data the interface needs
Review the objects passed from server code into client components. A convenience query that returns a complete account record can expose fields the UI never displays. Separate public view data from internal fields such as tokens, billing identifiers and administrative flags. Check error responses as well as successful responses.
Try this: Inspect the actual response to a sensitive page and confirm that it contains only the intended fields.
STEP 03
Review configuration as part of the release
A source change is only one input to an application build. Environment variables, dependency versions, caching choices and deployment settings influence the exposed behavior. Track the installed Next.js version and its security updates. Run the review against the release build so development-only assumptions do not obscure a production issue.
Try this: Pair source findings with a smoke test of the release artifact and a dependency audit of resolved package versions.
Your review checklist
- Authenticate and authorize every sensitive action and handler.
- Validate untrusted inputs before database or network operations.
- Select only required fields for client-facing responses.
- Keep server credentials outside public environment variables.
- Test access to cached or tenant-specific responses with two accounts.
- Review dependencies, deployment configuration and the release build.
What Bryxe can check
Bryxe includes checks for supported JavaScript and TypeScript patterns, exposed credentials and risky operations in modern web projects. Its focused code tool is useful while reviewing a handler or Server Action.
What you still need to verify
Static findings need application context. A scanner cannot infer all of your business permissions or verify every deployed cache boundary. Framework protections do not replace application-level authorization tests.
Common questions
Does use server make an action private?
No. Treat callable Server Actions as externally reachable operations and check the caller's identity and permissions before performing sensitive work. A server execution boundary is not an authorization policy.
Is protecting a page enough to protect its API?
Review the API independently. The caller may reach the endpoint without using your page. Confirm that the data access or handler layer enforces the permission your UI assumes.
Which Next.js version should I audit against?
Use the version installed in your project and its matching documentation. Check official security announcements and test updates before release. Do not copy assumptions from a guide written for a different major version.
Documentation & further reading
These primary sources explain the platform behavior discussed above. Check the documentation for the versions and configuration you use.