Improve Server Actions Documentation With Clear Security Guidance and Recommended Patterns

[kevinfiddick]

Goals

1. Clarify the security model of Server Actions so developers understand they are triggered by client requests and must be treated as network entry points.
2. Help developers avoid common unsafe patterns (e.g., overly generic mutation functions, missing authorization checks).
3. Provide explicit best practices for validation, authorization, and “least privilege” design when creating Server Actions.

Non-Goals

1. This proposal does not request changes to the Server Actions API or underlying mechanics.
2. This proposal does not address any framework vulnerabilities or bugs.
3. This proposal does not prescribe a specific security library or authentication solution.

Background

As teams adopt Server Actions, many developers interpret them as “internal server-only functions,” assuming they are inherently more protected than traditional API routes. This can unintentionally lead to risky patterns—for example, creating broad, highly privileged, or implicitly trusted actions like:

"use server";
export async function updateDatabase(collection, data) {
  // ...
}

In practice, Server Actions receive data directly from the client and should be written with the same security posture as any API endpoint. It appears that the current documentation does not strongly emphasize:

• The need for explicit authorization checks
• The need for strict input validation
• That Server Actions are still network-invoked
• That “least privilege” principles apply here as well
• That generic or cross-resource actions are dangerous in real-world apps

This has led to misunderstandings and unsafe usages in actual projects. Improving the documentation would help teams adopt Server Actions confidently and safely.

Proposal

Add an official section to the Server Actions documentation titled something like “Security Considerations” or “Best Practices for Safe Server Actions.”

This section could include:

1. Security Model Explanation

   • Server Actions run on the server but are still invoked by client requests.
   • Treat them like RPC endpoints or API routes in terms of validation and authorization.

2. Recommended Best Practices

   • Validate all input (e.g., schema validators).
   • Implement explicit authorization checks within each action.
   • Avoid generic mutation actions that bypass application-level constraints.
   • Limit the scope and responsibility of each action (“least privilege”).

3. Examples of Safe Patterns
   Showing how to check user identity, validate inputs, and restrict what can be mutated.

4. Common Anti-Patterns

   • Generic “update anything” actions
   • Using Server Actions for admin-level operations without additional checks
   • Assuming Server Actions are private or inaccessible from the client

These additions would significantly reduce real-world misuse and make Server Actions safer for teams adopting them at scale.

Are you interested in contributing?

Yes — I’m happy to help draft documentation improvements, contribute examples, or refine best practices if the team is open to it.

[icyJoseph]

• https://nextjs.org/docs/app/guides/data-security#built-in-server-actions-security-features

A lot of these are present in that guide. Gotta iterate a bit more perhaps.

[kevinfiddick]

Man, I am really not sure how I missed that! I appreciate the reply and I'll take a look over the documentation again tonight to see if there are any potential gaps, or if it was just me.

[icyJoseph]

There's likely more we can say and show though. Feedback is always welcomed!