Si të shtosh kontrollin e aksesit të bazuar në role (RBAC) në aplikacionin tënd

Për të shtuar kontroll aksesi të bazuar në role, jep çdo përdoruesi një ose më shumë role (për shembull admin, redaktues, shikues), përcakto cilat veprime mund t'i bëjë çdo rol, dhe kontrollo ato leje në server për çdo kërkesë — jo vetëm duke fshehur butonat. Kontrollo gjithashtu që regjistrimi që aksesohet t'i përkasë llogarisë ose ekipit të përdoruesit. Fillo me disa role fikse në bazën e të dhënave, dhe testo duke u përpjekur të arrish direkt të dhënat e një përdoruesi tjetër.

Vërtetimi kundrejt autorizimit

Dy fjalë që ngatërrohen shpesh:

• Vërtetimi është kush je ti? — hyrja në llogari. Shiko si të shtosh hyrje në llogari në aplikacionin tënd.
• Autorizimi është çfarë lejohet të bësh? — cilat faqe, regjistrime dhe veprime mund të arrijë një përdorues i kyçur.

RBAC është mënyra më e zakonshme për të bërë autorizim. Ka rëndësi: sipas shtatorit 2026, Broken Access Control është #1 në OWASP Top 10:2025, listën e gjerësisht të përdorur të rreziqeve më serioze të sigurisë së aplikacioneve web. Dështimet tipike janë përdoruesit që lexojnë të dhënat e përdoruesve të tjerë duke ndryshuar një ID në URL, ose përdoruesit e zakonshëm që thërrasin rrugë API vetëm për admin.

Zgjidh një model

Në praktikë, shumica e aplikacioneve kombinojnë dy gjëra: rolet për llojin e veprimeve që mund të kryejë dikush, dhe pronësinë për regjistrimet mbi të cilat mund t'i kryejë ato. "Redaktuesit mund të redaktojnë postime" është rregull roli; "…postime në hapësirën e tyre të punës" është rregull pronësie. Të duhen të dyja.

Fillo më thjesht se sa mendon. Admin, anëtar dhe shikues mbulojnë një numër të habitshëm aplikacionesh. Është më e lehtë të ndash një rol më vonë sesa të zgjidhësh dhjetë role që askush nuk i kupton.

Projekto rolet përpara se të shkruash kod

Shkruaj fillimisht një tabelë lejesh me gjuhë të thjeshtë. Shërben si specifikim për AI dhe si plan testimi:

Vendos edhe rastet kufitare: a mund të largohet pronari i fundit? A mund një admin të heqë pronarin? Çfarë shikon një përdorues i hequr?

Hap pas hapi

1. Fillimisht një hyrje që funksionon

RBAC qëndron mbi vërtetimin. Serveri duhet ta dijë me siguri kush po bën çdo kërkesë, nga një sesion ose një token i verifikuar — kurrë nga një ID përdoruesi që dërgon shfletuesi në trupin e kërkesës.

2. Ruaj rolet në bazën e të dhënave

Për një aplikacion me një ekip, një kolonë role te përdoruesit është e mirë. Për ekipe, përdor një tabelë anëtarësimi:

create table memberships (
  user_id uuid references users(id),
  organization_id uuid references organizations(id),
  role text not null check (role in ('owner','admin','member','viewer')),
  primary key (user_id, organization_id)
);

Mos lejo kurrë përdoruesit të vendosin rolin e vet përmes një përditësimi normal të profilit. Ndryshimet e roleve kalojnë përmes një endpoint-i të veçantë, me kontroll leje.

3. Kontrollo lejet në server, në një vend të vetëm

Shkruaj një ndihmës të vetëm — diçka si can(user, 'projects.delete', project) — dhe thirre atë në çdo rrugë API, veprim serveri dhe punë në sfond që lexon ose ndryshon të dhëna. Një funksion qendror është më i lehtë për t'u rishikuar dhe testuar sesa kontrollet e shpërndara nëpër kod. Refuzo si parazgjedhje: nëse asnjë rregull nuk e lejon një veprim, ai refuzohet.

4. Kufizo çdo pyetje

Çdo pyetje për të dhënat e ekipit duhet të përfshijë ekipin: where organization_id = :currentOrg, jo vetëm where id = :id. Kjo ndalon dikë të ndryshojë /projects/123 në /projects/124 dhe të shohë projektin e një kompanie tjetër. Kthe "nuk u gjet" në vend të "i ndaluar" për regjistrimet e ekipeve të tjera, që të mos zbulosh se ekzistojnë.

5. Shto mbrojtje në nivel baze të dhënash aty ku ka rëndësi

Siguria e nivelit të rreshtit (RLS) të Postgres e lejon bazën e të dhënave të zbatojë cilët rreshta mund të shohë secili përdorues. Është thelbësore nëse shfletuesi komunikon direkt me bazën e të dhënave (si me disa backend të hostuar), dhe një shtresë e dobishme e dytë për tabelat e ndjeshme përndryshe.

6. Pasqyro rolet në ndërfaqe

Tani fshi ose çaktivizo atë që përdoruesit nuk mund ta bëjnë, që aplikacioni të mos jetë i paqartë. Kjo është vetëm për përdorshmëri; kontrollet e serverit janë ato që mbrojnë.

7. Regjistro veprimet e ndjeshme

Regjistro kush ndryshoi role, fshiu të dhëna ose eksportoi regjistrime, dhe kur. Një regjistër auditimi ndihmon me pyetjet e mbështetjes dhe incidentet.

8. Testo si sulmues

Hyr si secili rol dhe provo çdo veprim në tabelën e lejeve. Pastaj provo gjërat që nuk duhet të funksionojnë: thirr rrugët API të admin si shikues, ndrysho ID-të në URL dhe kërkesa, hiq vetveten si pronari i fundit. Vlen të shkruhen teste automatike për tabelën e lejeve pasi rregullat të jenë stabilizuar.

Prompte që funksionojnë

Shto kontroll aksesi të bazuar në role. Role për organizatë: owner, admin, member, viewer, të ruajtura në një tabelë memberships. Lejet janë në këtë tabelë: [ngjit tabelën tënde]. Krijo një funksion të vetëm në server can(user, action, resource), refuzo si parazgjedhje, dhe përdore në çdo rrugë API. Kufizo çdo pyetje sipas organization_id. Fshi veprimet që përdoruesi nuk mund t'i kryejë në ndërfaqe, por mos u mbështet kurrë vetëm në atë për sigurinë.

Rishiko çdo rrugë API dhe funksion serveri në këtë aplikacion. Për secilën, listo çfarë të dhënash lexon ose ndryshon, nëse kontrollon që përdoruesi është i kyçur, nëse kontrollon rolin e tij, dhe nëse kufizon pyetjen sipas organizatës së tij. Rregullo ato që i mungon një kontroll, dhe më trego listën.

Shto një faqe /admin vetëm për admin ku pronari mund t'i ndryshojë rolet e anëtarëve. Parandalo heqjen ose ulën e pronarit të fundit në rol, regjistro çdo ndryshim roli me kë e bëri dhe kur, dhe sigurohu që endpoint-i i ndryshimit të rolit refuzon këdo që nuk është pronar.

Gabime të zakonshme

• Kontrollimi i roleve vetëm në ballinë. API-ja është ende e hapur për kushdo që e thërret.
• Besimi te ID-të nga klienti — një userId ose role në trupin e kërkesës në vend të sesionit.
• Pyetje pa kufizim që marrin regjistrimin vetëm sipas ID-së.
• Rolet kontrollohen në faqe por jo në rrugët API, eksporte, shkarkime skedarësh ose webhook-e.
• Admin sipas adresës email të ngulitur në kod (if email === 'me@...'), që është e lehtë të harrohet dhe e vështirë për t'u ndryshuar.
• Shumë role shumë herët, që askush nuk mund t'i shpjegojë gjashtë muaj më vonë.
• Sesione të vjetruara: një përdorues i ulur në detyrë mban të drejtat e admin deri sa del nga llogaria. Kontrollo rolet nga baza e të dhënave, ose rifresko ato, për veprimet e ndjeshme.

Lista e kontrollit për RBAC

• Tabela e lejeve e shkruar me gjuhë të thjeshtë, rastet kufitare të vendosura
• Serveri e njeh përdoruesin nga sesioni, kurrë nga të dhënat e kërkesës
• Rolet ruhen në bazën e të dhënave; përdoruesit nuk mund ta ndryshojnë vetë rolin e tyre
• Një kontroll qendror leje, refuzim si parazgjedhje, i përdorur në çdo rrugë
• Çdo pyetje e kufizuar sipas organizatës ose pronësisë së përdoruesit
• Siguria e nivelit të rreshtit aty ku shfletuesi mund të arrijë bazën e të dhënave
• Ndërfaqja fsheh atë që përdoruesit nuk mund ta bëjnë (vetëm për përdorshmëri)
• Veprimet e ndjeshme regjistrohen
• Çdo rol i testuar, duke përfshirë thirrjet direkte API dhe ID-të e ndryshuara

Kontrolli i aksesit është një pikë në një listë më të gjatë; lista e kontrollit të sigurisë për aplikacionet e ndërtuara me AI mbulon pjesën tjetër. Nëse po ndërton një mjet për stafin tënd, si të ndërtosh një mjet të brendshëm tregon ku përshtaten rolet.

RBAC në Mythex

Mythex nuk ofron një sistem të integruar hyrjeje ose rolesh për përdoruesit e aplikacionit tënd. Ti zgjedh një bibliotekë ose ofrues autentikimi dhe përshkruan rolet, dhe agjenti i lidh ato me kodin tënd dhe me bazën e të dhënave Postgres të projektit (shto hyrje në llogari në aplikacionin tënd). Rolet e hapësirës së punës së Mythex, si Owner dhe Member, kontrollojnë kush mund të modifikojë projektet e tua Mythex, jo kush mund ta përdorë aplikacionin që publikon. Përdor modalitetin Plan për të rënë dakord për tabelën e lejeve përpara ndërtimit, pastaj përdor prompt-in e rishikimit më sipër dhe testo çdo rol në Preview përpara se të publikosh. Prompte-t e sigurisë të dokumentacionit janë një vazhdim i dobishëm.

Pyetje