Zugriff mit Policies verwalten

Welcome! In this lesson, we'll dive into Supabase Storage Policies. These policies are your key to controlling who can access, upload, or delete files in your buckets.

Think of them as security guards for your cloud files, ensuring only authorized actions happen.

Without proper policies, your files could be vulnerable. Anyone could potentially upload malicious content, or sensitive user data might be publicly exposed.

• Prevent unauthorized access: Keep private files secure.
• Control uploads: Ensure only legitimate users can add files.
• Manage deletions: Prevent accidental or malicious file removal.

Policies are essential for building secure applications.

Just like with database tables, Supabase Storage uses Row-Level Security (RLS) for buckets. Before you can apply any policies, RLS must be enabled for your storage bucket.

You can do this in the Supabase dashboard under 'Storage' by clicking on a bucket and toggling 'Enable RLS', or directly with SQL:

Storage policies are written using SQL, similar to database RLS. They specify what actions are allowed (SELECT, INSERT, UPDATE, DELETE) and under what conditions.

Key parts of a policy:

• CREATE POLICY: Starts the policy definition.
• ON storage.objects: Specifies the table policies apply to.
• FOR [action]: Defines the operation (SELECT, INSERT, UPDATE, DELETE).
• USING / WITH CHECK: Sets the conditions for the policy.

Let's create a policy to allow anyone to read files from a specific bucket, for example, a 'public-images' bucket. This is common for assets like profile pictures or product images.

The auth.role() = 'anon' part means unauthenticated users, and auth.role() = 'authenticated' means logged-in users. We'll allow both here.

Now, let's create a policy that allows only authenticated users to upload files to a 'user-uploads' bucket. Crucially, we want them to only upload into a folder named after their own user ID.

We use auth.uid() to get the current user's ID and path_tokens[1] to check the first part of the file path.

To complement the upload policy, let's ensure authenticated users can *only* read files that they themselves own within the 'user-uploads' bucket.

This policy uses auth.uid() to match the owner of the file (which is stored in the owner column of storage.objects) and also checks the file path.

Storage policies operate on the hidden storage.objects table. This table stores metadata about every file in your buckets. Understanding its columns is vital for writing effective policies.

• id: Unique identifier for the object.
• bucket_id: The ID of the bucket the object belongs to.
• name: The full path and filename.
• owner: The auth.uid() of the user who uploaded the file.
• path_tokens: An array of strings representing the path segments.

Sometimes, only specific users (like administrators) should be able to delete files. Let's create a policy that allows deletion only if the user has a specific role, for example, an 'admin' role.

This requires a custom function to check user roles, or you can simplify by checking a specific `owner` UID if only one admin account exists.

After creating policies, it's crucial to test them thoroughly. You can do this by:

• Logging in as different users: Test with authenticated users, unauthenticated users, and users with different roles.
• Attempting forbidden actions: Try to upload, read, or delete files that your policies should prevent.
• Using the Supabase client: Make API calls with supabase-js or other client libraries and observe the responses (e.g., expecting 403 Forbidden errors).

Always verify your policies work as intended before deploying to production.

Great job! You've learned how to secure your Supabase Storage with policies. We covered:

• The importance of RLS for storage buckets.
• Creating policies for various actions (read, insert, delete).
• Using auth.uid() and path_tokens for granular control.
• Understanding the storage.objects table.

Implementing strong storage policies is crucial for the security and integrity of your application's file management.