Modelul de securitate

Lectură estimată: 4 minute

Estimare pentru text, la un ritm de 180 de cuvinte pe minut. Timpul pentru analizarea codului, exerciții și proiecte se adaugă separat și depinde de ritmul tău.

Problema pe care o vei rezolva: Matrice de acces pentru documente

Documentul D1 aparține lui A, D2 lui B. Contul C are email neverificat. Vizitatorul nu este autentificat. Regula laboratorului: numai proprietarul cu email verificat poate descărca.

Rezultatul urmărit

Construiește matricea celor patru identități pentru cele două documente. Implementează controlul pe ruta de descărcare și testează accesul direct la URL.

Cum recunoști o soluție corectă

A primește D1, B primește D2; accesul încrucișat, C și vizitatorul sunt refuzate conform contractului. Fișierul nu trebuie accesibil printr-un URL public alternativ.

Parcurge lecțiile în ordine și păstrează exercițiile în registrul descărcabil. Ultima lecție include atelierul de 40 de minute în care combini conceptele și testezi o variație a situației inițiale. Exemplele comerciale sunt fictive; nu reprezintă rezultate ale unor clienți.

Autentificarea („cine ești") și autorizarea („ce ai voie") sunt lucruri diferite, tratate în locuri diferite. Confuzia dintre ele produce fie găuri de securitate, fie cod încâlcit. Lecția asta clarifică modelul mental înainte de implementare.

Autentificare vs. autorizare

Autentificare: verifici identitatea. Login, sesiune sau token, „ești logat?".
Autorizare: verifici permisiunea. „Utilizatorul ăsta poate edita articolul ăsta?".
Ordinea: întâi autentifici (401 dacă eșuează), apoi autorizezi (403 dacă eșuează).

Unde stă fiecare în Laravel

Autentificare: middleware `auth`, guard-uri, `auth()->user()`.
Autorizare: Gates și Policies, `$this->authorize()`, `@can`, `->can()`.
Middleware `guest`: invers de auth (doar pentru neautentificați — pagini de login).

Straturi de apărare

Securitatea nu e un singur zid. Verifici la rută (middleware), la controller (authorize), și ascunzi în interfață (@can). Ascunderea în Blade e pentru experiență, NU pentru securitate — un utilizator poate oricând trimite cererea direct.

Ce vom construi

Un sistem complet: înregistrare cu verificare de email, login/logout, resetare parolă, roluri (admin/editor/user), permisiuni pe resurse (autorul își editează articolele), și acces la fișiere private.

Exercițiu

Pentru o aplicație la alegere, listează: ce rute necesită doar autentificare, ce rute necesită un rol anume, ce acțiuni necesită verificare pe resursă (owner). Marchează pentru fiecare codul de eroare corect (401 vs 403).

Greșeli frecvente

Folosești 403 când ar trebui 401 (sau invers).
Verifici permisiuni doar în Blade și crezi că e destul.
Amesteci logica de „ești logat" cu „ai voie" în același if.
Autorizezi înainte de a autentifica.

De reținut

Autentificare = cine ești (401); autorizare = ce poți (403).
auth middleware pentru prima, Gates/Policies pentru a doua.
Verifici în mai multe straturi; Blade e doar pentru UX.
Întâi autentifici, apoi autorizezi.

Pe scurt

Ține autentificarea și autorizarea separate, conceptual și în cod. Fiecare are locul ei, codul ei de eroare și stratul ei.

Autentificare, autorizare și validare în trei verificări

Autentificarea răspunde cine face cererea, autorizarea dacă poate face operația, iar validarea dacă datele au forma acceptată. Niciuna nu le înlocuiește pe celelalte. O cerere a unui utilizator autentificat poate fi refuzată pentru resursa altuia, chiar dacă payloadul este valid. Separă cele trei teste ca să poți localiza defectul. Nu folosi un câmp role sau user_id trimis de browser drept dovadă de drepturi.

Exemplu de lucru

Matrice:
Vizitator + payload valid → autentificare cerută.
User B + resursa lui A + payload valid → refuz acces.
User A + resursa lui A + payload invalid → eroare validare.
User A + resursa lui A + payload valid → succes.
Dovada succesului: răspuns corect și modificare DB permisă.

Interpretarea rezultatului

Matricea trebuie aplicată și endpointurilor mai puțin vizibile, precum export și descărcare. Ascunderea unui buton nu schimbă drepturile serverului. Verifică resursa după refuz pentru a demonstra că nu a fost modificată parțial.

Exercițiu de consolidare

Aplică matricea unui endpoint de descărcare PDF privat și descrie ce se întâmplă la o cerere directă fără cont.

Aplicație practică

Sarcina

Construiește matricea vizitator–client–editor–administrator.

Rezolvare orientativă și verificare

Pentru citire, creare, editare și ștergere stabilește explicit permisiunile și testează refuzurile.

Greșeală de evitat

Rolul din interfață nu trebuie acceptat de server ca adevăr.

Documentație și surse

Documentația Laravel 11 — versiunea aplicației demonstrative — Laravel
OWASP Top 10 — OWASP