🛡️ 1. عزل المفاتيح وتطبيق سياسات RLS المحكمة
في Supabase، توجد فئتان من المفاتيح:
NEXT_PUBLIC_SUPABASE_ANON_KEY: مفتاح عام يُستخدم في المتصفح ويجب أن يخضع لسياسات الأمان (Row Level Security).SUPABASE_SERVICE_ROLE_KEY: مفتاح أدمن شامل يتجاوز كافة القيود الأحدية، ويجب ألا يُستخدم إلا داخل السيرفر المحمي حصراً.
إذا تم العثور على مفتاح service_role داخل كود الواجهة أو سجل تغييرات Git، يجب تدويره فوراً عبر لوحة تحكم Supabase (Settings ➔ API ➔ Rotate Key).
كود إنشاء سياسة حماية الصفوف (RLS Policy)
تأكد من تفعيل الـ RLS على كافة الجداول وكتابة سياسات صريحة:
-- تفعيل الحماية على جدول المقالات
ALTER TABLE public.posts ENABLE ROW LEVEL SECURITY;
-- السماح للجميع بقراءة المقالات المنشورة فقط
CREATE POLICY "قراءة المقالات المنشورة مسماحة للجميع"
ON public.posts
FOR SELECT
USING (status = 'published');
-- السماح للمستخدم فقط بتعديل مقالاته الخاصة
CREATE POLICY "المستخدم يعدل مقالاته فقط"
ON public.posts
FOR UPDATE
USING (auth.uid() = user_id);
🧪 2. التحقق من صحة المدخلات بواسطة Zod Schemas
تجنب الاعتماد على الفحص البسيط في الواجهة؛ استخدم مكتبة Zod لإلزام السيرفر بهيكلية دقيقة قبل معالجة البيانات:
import { z } from 'zod';
export const CreatePostSchema = z.object({
title: z.string().min(5, 'العنوان قصير جداً').max(150, 'العنوان طويل جداً'),
content: z.string().min(20, 'محتوى المقال غير كافٍ'),
category: z.string().nonempty('التصنيف مطلوب'),
status: z.enum(['draft', 'published']).default('published'),
});
export type CreatePostInput = z.infer<typeof CreatePostSchema>;
🎯 3. بروتوكول التطوير القائم على الاختبارات (TDD Protocol)
التعديل المباشر على الأكواد دون إجراء اختبارات محاكية ينتهي دائماً بأخطاء تراجع عكسية (Regressions).
قبل اعتماد أي تغيير معماري في المشروع، يرجى اتباع التسلسل التالي:
تشغيل فحص الأنواع الصارم:
npx tsc --noEmit.تشغيل اختبارات الوحدة:
npm test.التحقق من سلامة البناء للإنتاج:
npm run build.
📋 الخلاصة
الأمان والهيكلية النظيفة ليسا خياراً إضافياً بل هما أساس المشروع الناجح. بتطبيق سياسات RLS وفحص البيانات بـ Zod، تضمن استقرار تطبيقاتك وحمايتها من أي ثغرة!




