Skip to content

Supabase Shared Profiles: Review Access Changes

Review public, protected and private profile data through ownership, recipient approval and access removal in an authorized Supabase prototype.

GuidePersonal life

By

Updated 2 min read
Test what changes when a sharing decision changes: database illustration with IndieTools branding

A selectively shared profile needs a clear rule for every transition: publishing an item, approving a recipient, hiding content and removing access. Review those changes against the data returned to each reader, not only the labels displayed to the owner.

The Supabase catalogue, observed on October 3, 2026, includes TodayMet. Its listing describes Public, Protected and Hidden material with owner-approved requests and private links. Supabase is a declared stack association; this guide does not claim to have audited TodayMet's policies or access behaviour.

Start with a small sharing matrix

In a prototype or authorized test workspace, create an owner, an approved recipient and an unrelated account. Add synthetic items representing each visibility level. Write down who should discover each item and who should read its contents.

Discovery and reading are separate operations. Hiding a field's value while exposing its sensitive title can still violate the intended sharing rule. Include list views, search results and item counts in the matrix when they reveal information about private material.

Keep account identity explicit throughout the exercise. A browser that remains signed in as the owner cannot establish what an anonymous visitor or an unrelated reader receives.

Check both existing and resulting data

Supabase's Row Level Security documentation describes policies for individual database operations. Update policies can distinguish which existing rows may be changed from what the resulting row is allowed to contain. The application must configure those rules for its actual ownership model.

Use that distinction when reviewing a move from private to public. The operation should require the right actor and preserve the correct owner, rather than accepting a client-provided owner identifier as authority.

Test only systems you own or have permission to assess. A public directory association is an invitation to research a product, not permission to probe its private endpoints.

Revisit access after a decision changes

Approve one recipient and confirm the intended item becomes available. Then withdraw that approval using the documented control and inspect subsequent requests from the recipient's session. Record whether already downloaded copies fall outside the revocation promise.

Change an item's visibility while another session remains open. The product should have a documented freshness rule for cached views and later requests. An old screen is not proof that the server still authorizes a new read, so inspect those outcomes separately.

Include a pending request that is never approved. Waiting for owner review should not temporarily expose the requested material or imply that access has already been granted.

Connect files to the same policy

A profile may protect its database fields correctly while exposing an attached file through a different path. Review the Supabase document-link lifecycle alongside this sharing matrix, especially for downloadable private material.

The final acceptance record should contain the actors, transitions, expected responses and observed results. Preserve unresolved cases with their scope. That gives a team a practical review artifact without turning one successful sharing test into a claim that every part of the product is secure.

More from the blog