Next.js Server Actions: Broken access control

Server-side code still needs a permission check.

Next.js Server Actions let the browser call a function that runs on the server. The real function stays on the backend. The client receives a reference to it: an action ID.

Here is a simplified example of the mistake:

'use server'

export async function getUserName(email) {
  // Missing: who is asking, and may they read this user?
  return db.users.find({ email })
}

Calling it from the page produces an HTTP request. In the apps I tested, simple arguments were sent as a JSON array:

POST / HTTP/2
Host: [ masked ]
Accept: text/x-component
Next-Action: <action-id>
Content-Type: text/plain;charset=UTF-8

["someone@example.com"]

The Next-Action header identifies the function. Next.js decodes the arguments, calls the function, and sends its result back in a React response. More complex arguments can use a different encoding, so the browser's own request is the best starting point.

The important question is what happens inside that function. Before reading private data or changing anything, it needs to verify the caller's identity and permissions. Next.js describes this in its Server Actions security guide.

An action ID identifies a function. It does not authorize the caller. If a page sends that ID to the browser, a visitor can inspect it and use it in a direct request. Hiding an admin button does not protect the action behind it.

A note on action IDs

I call them hashes in my notes, but action ID is the more useful term. Their format depends on the Next.js version. Modern builds generate encrypted, non-deterministic IDs and can remove unused actions. Those protections do not replace authorization. See the current Next.js documentation.

In these cases, I saw both 40- and 42-character hex IDs. A pattern such as [0-9a-f]{40,} avoids cutting the longer ones short. A hex string alone is only a lead: check that it is actually used as an action reference.

How I found the missing check

1. Find the action in the browser

Start with the App Router page and watch its network requests. A request carrying Next-Action gives you the action ID, route, and argument format together.

Other useful clues are self.__next_f in the HTML and React responses with Content-Type: text/x-component. Files under /_next/static/chunks/ are worth reading, but that path alone does not confirm that a page uses Server Actions.

2. Connect action IDs to function names

Read the JavaScript around each action reference. Names such as saveMedia, getUserName, and getPresignedUrl tell you which business operation to investigate.

This console helper recognizes a common webpack output format. It lists candidate IDs and, where possible, their export names:

(async () => {
  const urls = new Set(
    [...document.querySelectorAll('script[src*="chunks"]')]
      .map(script => script.src)
  )

  const html = document.documentElement.innerHTML
  for (const match of html.matchAll(
    /static\/chunks\/(\d+-[0-9a-f]+\.js)/g
  )) {
    urls.add(new URL(
      '/_next/static/chunks/' + match[1], location.origin
    ).href)
  }

  const actions = []
  const seen = new Set()

  for (const url of urls) {
    let code
    try {
      const response = await fetch(url)
      if (!response.ok) continue
      code = await response.text()
    } catch {
      continue
    }

    const chunk = (code.match(/push\(\[\[(\d+)/) || [, '?'])[1]
    const references = {}

    for (const match of code.matchAll(
      /([\w$]+)\s*=\s*\(0,[^)]+\)\(\s*"([0-9a-f]{40,})"/g
    )) {
      references[match[1]] = match[2]
    }

    for (const match of code.matchAll(
      /([\w$]+):function\(\)\{return ([\w$]+)\}/g
    )) {
      const id = references[match[2]]
      if (!id || seen.has(id)) continue
      actions.push({ name: match[1], id, chunk })
      seen.add(id)
    }

    for (const id of Object.values(references)) {
      if (seen.has(id)) continue
      actions.push({ name: '(unresolved)', id, chunk })
      seen.add(id)
    }
  }

  console.table(actions)
})()

This is a starting point, not a complete inventory. It can miss lazy-loaded chunks and other bundle formats. Open the relevant pages, inspect the references, and refresh your notes after a new deployment.

3. Replay a known request without authentication

Choose an action you understand. Copy its request into Burp Repeater, remove cookies and any authorization header, and compare the result. Keep the route and argument format from the original request.

For a read-only action that takes no arguments, a request can look like this:

POST / HTTP/2
Host: [ masked ]
Accept: text/x-component
Next-Action: <action-id>
Content-Type: text/plain;charset=UTF-8

[]

Do not send empty arguments blindly to actions that import, delete, sync, or send email. Understand the operation first. For a write test, use a record you control and verify the change by reading it back.

The entry point was similar in all three apps. The impact depended on what the exposed function could do.

1. 01Create a user. Grant an API key. Reach the admin API.A generic database write led to access to users, contracts, vendors, and internal records.
2. 02Read content, change records, and obtain an S3 upload.29 exposed actions; over 16,000 records in the returned content data.
3. 03Retrieve user profiles and private partner details.Email and domain lookups returned far more information than the page needed.

Check permission where the work happens.

All three apps trusted a request that should have been checked. The function ran on the server, but the caller still controlled its arguments.

• A broad write let me create an identity and give it credentials.
• Unprotected reads and updates exposed private content and let me change it.
• An unprotected upload action granted write access to an S3 object.
• Returning every field exposed profile and partner details the page did not need.

What needs to change

1. Verify identity and permission before sensitive work. A valid session is only the first check. Confirm the user's role, tenant, and access to the specific resource.
2. Keep the check close to the data. Use a shared data-access layer or enforce it inside each action. A page redirect, hidden button, or middleware check should not be the only control.
3. Accept only the fields the operation needs. Replace generic collection writes with specific operations. Ordinary callers should not be able to set roles, API keys, or authentication flags.
4. Return a deliberate response shape. Choose the fields the caller is allowed to see. Do not send a full database row simply because the query returned one.
5. Constrain upload permission. Authorize the upload workflow and limit the object path, accepted content, and URL lifetime. A public upload feature still needs tightly scoped access.

Next.js covers session verification, authorization, and returning minimal data in its authentication guide.

'use server'

export async function updateMedia(input) {
  const user = await requireUser()
  const data = mediaUpdateSchema.parse(input)
  const record = await loadMedia(data.id)

  if (!record || !(await canEditMedia(user, record))) {
    throw new Error('Forbidden')
  }

  const saved = await db.media.update({
    where: { id: record.id },
    data: { name: data.name, alt: data.alt }
  })

  return { id: saved.id, name: saved.name }
}

Illustrative, not drop-in code. The session, schema, data-access, and permission helpers belong to your app. They must enforce its role, tenant, and resource rules.

After fixing the action, repeat the original request without a session and with users who lack permission. Confirm both that access is denied and that no data was changed.

The action ID tells the server what to run. Your permission check decides whether it should.

Request template

POST /<route> HTTP/2
Host: <target>
Accept: text/x-component
Next-Action: <action-id>
Content-Type: text/plain;charset=UTF-8

<json-array-of-arguments>

Use the route, full action ID, and argument encoding from the app's own request. IDs are specific to the app and build; the recorded examples are not universal values.