Next.js + Supabase Client Portal: Security Checks Before Launch

A customer portal can be beautiful, fast and well thought out, while remaining fragile on the essentials. In practice, a few oversights are enough to expose data, break a permission, or leave a sensitive action too easy.

Before going online, the most useful thing is not an abstract speech on security. The most useful thing is a concrete check of the points that break most often.

1. Check the client/server border

The first control is simple: everything that affects a secret, an admin role or a privileged action must remain on the server side.

Look for:

• the use of service_role
• sensitive environment variables
• modules imported into components "use client"

If the border is blurred, correct it before the rest.

2. Check roles and paths

A customer portal often relies on several types of users:

• administrator
• internal collaborator
• end customer

You have to check that each route sees exactly what it should see, and nothing more.

Test with real accounts of each type. Don't just rely on your admin account.

3. Check the GRANT of the exposed tables

If your portal uses the Supabase Data API, the accessible tables must have their own explicit GRANT. Since the 2026 changes to Supabase, this point is even more important.

Ask yourself this question table by table:

• Does anon need it?
• Does authenticated need it?
• service_role is alone enough?

A too wide GRANT is not a detail. It is a direct exposure surface.

4. Check EPIRB and policies

An accessible table is not yet a well-secured table.

Check:

• that the EPIRB is activated
• that the policies cover the readings well
• that they cover the useful scriptures well
• that they filter with the right identifiers

The right test is very concrete: user A must never see or modify B's data without clear product justification.

5. Check sensitive actions

Certain actions deserve a separate review:

• account deletion
• role change
• admin access
• data export
• reading invoices, messages, documents

These actions must go through clear server control, with explicit verification of rights.

6. Check public content

Many portals mix:

• public content
• private content
• semi-public CMS-type content

Verify that public tables do not give more than what should be visible to a disconnected visitor.

This control is easy to forget when the project combines marketing site and customer area.

7. Check secrets and environment

A clean upload also requires:

• no secret prefix by NEXTPUBLIC
• no sensitive key in the repo
• variables defined correctly on the production environment
• no confusion between public keys and server keys

This point seems basic, but it comes up very often.

8. Check security headers

A customer portal should come out with a clean base on headers:

• Content-Security-Policy
• Strict-Transport-Security
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

The goal is not to pile up headers without understanding them, but to cover the real useful areas.

9. Check behavior in case of error

Security is not just about access. This is also the way the application reacts:

• does a user see a clear message if access is refused?
• does an error reveal too much internal information?
• does the front continue to display data after an invalid session?

A healthy portal handles both rejections and successes.

10. Check with a pre-production checklist

Before opening to the public, do a final pass:

1. test with customer account
2. test with internal account
3. test with account without rights
4. testing critical actions
5. checking exposed tables
6. checking secrets and headers

If you're short on time, at least do this. This is the heart of the risk.

What to remember

A Next.js + Supabase client portal can be very clean if you check the right points before going live: server/client border, GRANT, RLS, sensitive actions, public content, secrets and headers.

The biggest danger isn't a spectacular bug. It's a sum of small oversights which, together, open a real gap. A simple and disciplined checklist already avoids a lot of problems.

Official sources

• Supabase - Securing your API
• Supabase - Understanding API keys
• Supabase - Row Level Security
• Next.js - headers in next.config.js