ClipSync: Building a Secure, Real-Time Clipboard Manager Without a Custom Backend

Most web apps have a custom API server between the browser and the database. The browser calls the server, the server validates the request, checks permissions, and talks to the database. That chain is familiar, but for a solo project it also means writing, deploying, and maintaining an entire service that mostly exists to proxy queries.

ClipSync takes a different approach: the browser talks directly to Supabase over HTTPS. There is no custom application server in the request path. The front end, a Next.js 15 App Router app deployed on Vercel, holds a single Supabase client instance configured with the project URL and the publishable key. All reads and writes go from the browser to Supabase directly, authenticated by the user's JWT.

That sounds like it should be insecure. It is not, because authorization is handled at the right layer.

The publishable key only allows making requests. What those requests can actually read or write is controlled entirely by Postgres Row Level Security, which is enforced at the database before any data is returned or modified. The service role key, which can bypass that security, is never shipped to the client and is not used by the application at all.

Row Level Security is a Postgres feature where access policies are attached to table rows. Every table in ClipSync carries a user_id column. Every policy checks auth.uid() = user_id for select, insert, update, and delete.

When a request arrives, Postgres evaluates the policy before returning or modifying any data. Even a direct request to the Supabase endpoint with a valid JWT can only touch rows where the authenticated user id matches.

This is the real security boundary, not the UI. The client-side route guard in auth-provider.tsx redirects unauthenticated users to the login page. That is a UX concern. If it were removed or bypassed, the database policies would still hold. A user cannot read or modify another user's rows regardless of what the client sends.

The practical consequence: authorization comes free at the data layer. There is no permission-checking middleware to write, no server route to forget, and no code path that might accidentally expose one user's data to another.

Four tables, one security model:

There is no device pairing step in ClipSync. Identity is just the signed-in user. Signing in on a second device with the same account gives the same user id, and Row Level Security returns the same rows. Cross-device identity is authentication, nothing more.

For live updates, the useClips and useSavedPages hooks subscribe to Postgres change events via Supabase Realtime, filtered to the current user's user_id.

Insert, update, and delete events are applied to the local Zustand store directly, without a full refetch. A clip added on a phone appears on a signed-in laptop within about a second. Because Realtime also respects Row Level Security, a device only receives events for its own user's data. The subscription is set up inside each hook alongside the initial data fetch, and unsubscribed on unmount to prevent leaked channels.

The project originally shipped with a single-user lock: a config table row recording the first registered email address, checked on every login. Anyone other than that email was denied, at the application level.

Removing it required no schema changes. Row Level Security was already in place and already isolated each user's data. Lifting the gate did not weaken data separation because the gate was never the isolation mechanism. It only controlled who could get a JWT. Once gone, anyone can sign up and receive their own private workspace.

The distinction matters: application-level gating and database-level multi-tenancy are different things. RLS provides the isolation. The lock was a restriction on top of it. Once I understood that, removing it was a small change. The dead lock functions were deleted afterward to prevent leaving dead code.