1Secure my website, dashboard, CRM and paid courses. Act as a senior security engineer. Start with an audit of the current code, give me a list of risks ranked by severity, then fix them in phases. Explain each fix in one simple sentence.
2
3## 1. Accounts and admin
4- Admin login with Supabase Auth plus 2FA (TOTP) required for the owner and editors.
5- Protect /admin and every admin API route on the server (middleware + server checks), never only in the UI.
6- Session expiry, logout from all devices, and an audit log of every admin action (who, what, when, IP).
7- No secret keys in client code. Service role key used only in server code. All keys in environment variables, with a .env.example and nothing secret committed to git.
8
9## 2. Database
10- Row Level Security on every table, no exceptions. Write tests that prove a logged out user and a student cannot read contacts, payments, drafts or other students' data.
11- Public can only read published content and insert form submissions.
12- Use parameterized queries only. Validate all input with Zod on the server.
13- Daily backups and a tested restore steps doc.
14
15## 3. Public forms and CRM data
16- Cloudflare Turnstile on every form, rate limiting per IP and per phone/email, honeypot field.
الرئيسيبيشتغل مع أي موديل شاتماركداون
تعمل إيه بالرد
متصلحش كل حاجة. رتب الجدول حسب "ليه ده مهم" وصلّح أول تلاتة. وبعدين شغّله تاني.
17- Sanitize all text before showing it in the dashboard (no XSS from form submissions).
18- Contacts' phone numbers, emails and payment screenshots are private: private storage bucket, short lived signed URLs, admin only.
19- Consent checkbox, privacy policy page (Arabic and English), and a way to export or delete a person's data on request. Follow Egypt's Personal Data Protection Law.
20
21## 4. Course security (most important)
22Student area:
23- Add a student area at /learn. Students log in with email magic link or WhatsApp/phone OTP.
24- A student gets access to a course only when I confirm their payment in the CRM. Access can be per course, per level, with an optional expiry date.
25- I can revoke access from the contact profile in one click.
26
27Videos:
28- Host course videos on Bunny Stream (or Mux) with token authentication: signed URLs that expire in a few hours and only play on my domain.
29- Never expose raw video file URLs. No download button.
30- Show a moving, semi transparent watermark over the video with the student's name and phone number, so leaked recordings can be traced.
31
32Files and links:
33- Prompt packs and project files in a private Supabase bucket, delivered through signed URLs that expire in minutes, and each download is logged per student.
34- Live session links (Zoom or Meet) only appear inside /learn for enrolled students, shortly before the session. Never send them in public places.
35
36Account sharing:
37- Limit each student to 2 devices. Logging in on a third device logs out the oldest one.
38- Flag suspicious activity in the CRM: many IPs or countries on one account, many downloads in a short time, many concurrent sessions. Show a "possible sharing" badge on the contact.
39
40## 5. Payments
41- Never trust payment status from the browser. Only an admin confirming in the dashboard (or a verified payment provider webhook with signature check) can grant access.
42- Payment screenshots are private and only visible to admins.
47- HTTPS only, secure and httpOnly cookies, SameSite.
48- CSRF protection on all mutations.
49- File uploads: check type and size on the server, strip image metadata, never execute uploads.
50- Rate limit login, OTP and form endpoints.
51- Run npm audit, update vulnerable packages, enable Dependabot.
52- Error pages that never show stack traces or database errors to visitors.
53- Monitoring: Sentry for errors, alerts for spikes in failed logins or form spam.
54
55## 7. Deliverables
561. Security audit report of the current code, ranked by severity
572. Fixes in phases: admin and secrets, database RLS and tests, forms and CRM data, student area and course protection, payments, headers and monitoring
583. A SECURITY.md that explains in simple words how everything is protected and what I must do (rotate keys, check the audit log, restore a backup)
594. A short checklist I run before every deploy
60
61Show me the plan before writing code. Ask before adding any paid service.