Sekuriteit & Vertroue

Sekuriteit leef in Postgres, nie in toepassingsdissipline nie. Elke produk aktiveer Row-Level Security op elke tabel, van dag een af.

• Multi-huurder-produkte (AdminOS) dwing isolasie af deur die JWT tenant_id met die ry tenant_id te vergelyk in 'n RLS-beleid op elke tabel — tenant_id word altyd bedienerkant uit die geverifieerde token opgelos, nooit van die kliënt af vertrou nie.
• Die bevoorregte diens-rol-sleutel is beperk tot slegs-bediener-paaie (webhooks, cron, fakturering) en bereik nooit die blaaier nie; standaard lees-/skryfaksies loop onder die gebruiker se RLS-konteks.
• Slegs-gepubliseerde publieke leesaksies, slegs-outeur-opdaterings, en sagte-skrap (deleted_at) is die verstek-RLS-houding — rekords word nooit hard geskrap nie.

Elke inkomende webhook word kriptografies geverifieer voordat dit data kan raak — met konstante-tyd-vergelyking en, waar relevant, 'n herhaling-wag.

• Meta WhatsApp Cloud API: HMAC-SHA256 oor die rou liggaam (x-hub-signature-256), vergelyk met 'n tydveilige gelykheidskontrole; 'n ongeldige handtekening is 'n 401.
• PayFast ITN: MD5-handtekening plus 'n bron-IP-kontrole voordat enige plan- of bestellingtoestand verander.
• Interne stelsel-tot-stelsel-oproepe (winkel ↔ enjin): Bearer-sleutel + HMAC-SHA256(liggaam) uitgaande; handtekening oor timestamp.body inkomend, met 'n vyf-minuut-herhalingsvenster.
• Paystack (True Access): HMAC-SHA512-verifikasie op die betaling-webhook.

Publieke oppervlaktes word toegehek voordat hulle die databasis of 'n LLM bereik, sodat koste en misbruik begrens is.

• Rand-beskerming (Arcjet) vir bot-, tarief- en skild-reëls op die studentgerigte produk.
• Upstash-glydende-venster-beperkers op API-, webhook-, AI- en aanboording-paaie — as singletons gekas om te verhoed dat Redis-verbindings weer oopgemaak word.
• Per-eindpunt-AI-begrotings en per-plan-daaglikse-tokengrense, afgedwing in Redis met 'n 429 by uitputting.

'n Publieke WhatsApp-nommer is 'n oop pyp na 'n taalmodel. Onbetroubare invoer word by ingestie ontsmet, voordat dit ooit gestoor word.

• Inkomende boodskappe word deur 'n ontsmetter gevoer (16–17 inspuitingspatrone + 'n 2,000-karakter-limiet) voor enige databasisskryf — sodat geen kwaadwillige loonvrag volgehou of herhaalbaar is nie.
• Admin-verskafte konfigurasie kry 'n aparte, strenger ontsmetter om kruis-huurder-kasvergiftiging te voorkom.
• Stelselprompts word in die model se stelselparameter geïsoleer met efemere kasing, sodat ingespuite gebruikersinhoud nie 'n gekaste prompt kan korrupteer nie.

Tokens bly uit die blaaier, geheime bly uit die bondel, en elke reaksie word met verharde opskrifte gelewer.

• Sessies gebruik HTTP-only-koekies — geen auth-tokens in localStorage nie; OAuth loop deur PKCE.
• Diens-rol-, model- en webhook-geheime word nooit as NEXT_PUBLIC blootgestel nie en nooit gelogboek nie; 'n gedokumenteerde inventaris ken 'n rotasie-eienaar toe.
• Sekuriteitsopskrifte word op alle roetes geoudit: HSTS (met preload), X-Frame-Options: DENY, X-Content-Type-Options: nosniff, 'n Content-Security-Policy, en 'n beperkende Permissions-Policy.

Sensitiewe stelsels hou 'n knoei-duidelike rekord van wat gebeur het — deur konstruksie, nie deur konvensie nie.

• Die ouditlogboek het UPDATE- en DELETE-voorregte op die databasisvlak ingetrek — nie eens die diens-rol kan 'n inskrywing verander nie.
• Finansiële rekords (bydraes, uitbetalings, lenings) dra unieke kwitansienommers en 'n recorded_by-verwysing; 'n onveranderlike voor-/na-toestand word per verandering vasgevang.
• Inkomende webhook-IDs word UNIQUE gestoor om verskaffer-herprobeerings te ontdupliseer.