La lliçó anterior va deixar CicloUrbana amb un forat que arrossegàvem des del principi del mòdul. La Marta té un token vàlid amb el rol ROLE_CIUTADA, així que la seva petició POST /api/v1/lloguers/9/finalitzar travessa la cadena de filtres sense ni un problema: la ruta està permesa a usuaris autenticats i el rol és correcte. Però el lloguer número 9 és d'un altre ciutadà de Ribalta. La Marta acaba de tancar el lloguer d'un desconegut, i l'import se li ha cobrat a ell.

Cap regla d'authorizeHttpRequests no ho pot impedir, perquè la resposta no depèn de la ruta ni del rol: depèn de la dada. Aquesta lliçó baixa la seguretat fins a la capa on viu la lògica de negoci, amb @EnableMethodSecurity, @PreAuthorize i expressions SpEL, i després tanca el mòdul endurint l'API sencera: CORS per entorn, limitació de taxa, HTTPS obligatori, ocultació de la documentació en producció, auditoria d'esdeveniments, revisió de dependències vulnerables i una llista de comprovació abans d'exposar la xarxa de Ribalta a Internet.

Advertiment que es repetirà al final, perquè és el més important del mòdul. Tot el que hem construït en aquestes cinc lliçons és un punt de partida didàctic. Abans d'exposar un servei real a Internet, la configuració de seguretat ha de ser revisada per un professional de seguretat i sotmesa a una auditoria independent. Els secrets no es versionen mai, i cap llista de comprovació no substitueix una prova de penetració feta per algú que no ha escrit el codi.

1. Per què les regles per URL no basten
2. @EnableMethodSecurity i les seves anotacions
3. SpEL a les expressions de seguretat
4. Un avaluador de permisos propi: SeguretatLloguers
5. @PostAuthorize i @PostFilter: el cost de filtrar tard
6. On posar les anotacions: proxies i autoinvocació
7. Enduriment de l'API
8. Els riscos OWASP i la seva mitigació a CicloUrbana
9. Auditoria d'esdeveniments de seguretat
10. Dependències vulnerables
11. Llista de comprovació abans de producció
12. Errors Comuns i Consells
13. Exercicis

Les regles de 05-02 són necessàries i són la primera línia de defensa, però tenen tres límits estructurals:

No poden expressar regles que depenen de la dada. «Només els teus propis lloguers» no és una propietat de la ruta /api/v1/lloguers/9/finalitzar: és una relació entre l'usuari autenticat i la fila 9 de la taula. L'URL és idèntic tant si el lloguer és propi com aliè.

La mateixa operació s'assoleix des de diversos llocs. LloguerService.finalitzar el crida avui LloguerController; demà el cridarà una tasca programada (07-03), un consumidor de missatges o un endpoint nou, i cada punt d'entrada és una oportunitat d'oblidar la comprovació. Posar la regla al servei l'aplica una sola vegada i per a tots.

La protecció és lluny de la regla. Qui llegeix LloguerService no veu cap comprovació i l'ha de buscar en un altre fitxer, en un altre paquet, escrita com un patró de ruta. La seguretat declarada al costat del mètode que protegeix és la que es manté actualitzada.

No són alternatives, són capes. La regla per URL descarta aviat el que no ha ni d'arribar; la de mètode aplica el que només es pot decidir amb la dada a la mà:

S'activa amb una anotació en una classe de configuració:

A Spring Security 6, @EnableMethodSecurity substitueix l'antic @EnableGlobalMethodSecurity i activa per defecte @PreAuthorize i @PostAuthorize. Els seus atributs habiliten la resta: @EnableMethodSecurity(securedEnabled = true, jsr250Enabled = true) hi afegeix @Secured i @RolesAllowed.

El criteri: fes servir @PreAuthorize tret que tinguis una raó concreta. És l'única que combina avaluació primerenca amb expressions completes; @Secured i @RolesAllowed només admeten una llista de rols, cosa que ja cobreixen les regles per URL; i tot el que s'avalua després implica que el mètode ja s'ha executat, amb el seu cost i els seus efectes secundaris.

Les expressions s'escriuen en SpEL (Spring Expression Language) i disposen d'un vocabulari propi:

Exemples reals del projecte:

Aquesta última expressió és l'exemple canònic i mereix desgranar-se. #idUsuari es refereix al paràmetre del mètode pel seu nom; principal.idUsuari invoca getIdUsuari() sobre l'UsuariAutenticat de 05-03 —aquí es cobra per segona vegada la decisió de crear un UserDetails propi: amb el User estàndard no hi hauria cap id per comparar—; i or hasRole('ADMIN') hi afegeix l'excepció administrativa.

Compte amb els noms de paràmetre. #idUsuari només funciona si el compilador conserva els noms dels arguments. El spring-boot-maven-plugin activa -parameters per defecte, però si el projecte ho perd, l'expressió falla en temps d'execució amb un missatge confús. L'alternativa robusta és @P("idUsuari") sobre el paràmetre, o #p0 per posició —menys llegible—.

I un advertiment de fons: SpEL s'avalua en temps d'execució i no el comprova el compilador. Un error tipogràfic a hasRole('OPERRARI') o a principal.idUsuarri no impedeix compilar ni arrencar: falla a la primera crida real, o pitjor, denega sempre. És la raó que aquestes expressions necessitin proves automàtiques, que és exactament el que comença al mòdul 6.

Tornem al problema del principi. La regla és: un ciutadà només pot finalitzar els seus propis lloguers; un operari o un administrador, qualsevol. Es podria intentar a l'anotació:

Aquesta expressió no es pot provar de manera aïllada, no l'entén qui la llegeix, amaga una consulta a la base de dades dins d'una cadena de text i no compila res del que hi ha a dins. La solució idiomàtica és un bean de seguretat:

Cinc avantatges d'aquesta forma, i són els que la converteixen en la recomanada:

1. És llegible. «És operari o administrador, o és el propietari» es llegeix de seguida i es pot ensenyar a l'ajuntament.
2. És comprovable. SeguretatLloguers és un bean normal: es prova amb JUnit i Mockito (06-02, 06-03) sense aixecar el context de seguretat.
3. És reutilitzable. La mateixa expressió serveix a obtenirPerId, a cancellar i a qualsevol mètode futur.
4. És eficient. existsByIdAndUsuariId és una consulta derivada (04-06) que retorna un booleà; no carrega l'entitat ni les seves relacions.
5. Concentra el canvi. Si demà un ciutadà pot gestionar els lloguers d'un familiar autoritzat, es canvia un mètode Java, no set anotacions.

Fixa't en l'ordre de l'expressió: hasAnyRole va primer a propòsit. SpEL avalua or en curtcircuit, així que per a un operari la consulta a la base de dades ni tan sols s'executa.

I amb això el forat està tancat. La petició de la Marta sobre el lloguer aliè ja no arriba al cos del mètode: AccessDeniedException puja pel proxy, ExceptionTranslationFilter la tradueix i el AccessDeniedHandler de 05-03 retorna un 403 amb format ProblemDetail.

Un matís de disseny. Retornar 403 confirma que el lloguer 9 existeix. En un servei on la mera existència sigui informació sensible, la resposta correcta és 404: «aquí no hi ha res per a tu». Per a CicloUrbana el 403 és acceptable i més clar; en una aplicació amb dades delicades, planteja't el 404.

@PostAuthorize avalua l'expressió després d'executar el mètode, amb accés a returnObject:

És còmode quan el permís depèn d'una dada que només es coneix després de consultar, i té dos costos: el mètode ja s'ha executat, amb les seves consultes i el seu temps, i qualsevol efecte secundari ja ha passat. D'aquí una regla dura: no facis servir mai @PostAuthorize en un mètode que escriu. Si fa un càrrec, envia un correu o canvia l'estat d'una bicicleta, denegar l'accés a posteriori no desfà res; amb @Transactional l'excepció sí que provoca rollback de la base de dades (04-07), però no del correu enviat ni de la crida al proveïdor de pagaments.

@PostFilter recorre la col·lecció retornada i n'elimina els elements que no passen l'expressió:

El problema és d'eficiència i d'escala. Si la xarxa de Ribalta té 40.000 lloguers, aquest mètode els porta tots, construeix 40.000 DTO i en descarta 39.987 en memòria. I amb la paginació de 04-05 el resultat és directament incorrecte: es demana la pàgina 0 amb 20 elements, el filtre en descarta 18 i el ciutadà rep una pàgina de 2 amb un total que menteix. La solució correcta és filtrar a la consulta, enllaçant amb 04-06:

La regla pràctica: @PostFilter només per a col·leccions petites i acotades —els quatre estats d'una estació, la llista de tarifes— i mai sobre resultats paginats. Per a tota la resta, la seguretat forma part de la consulta.

Les anotacions van al servei, no al controlador, per tres raons: el servei és el punt pel qual passen tots els camins, inclosos els futurs; el controlador s'ocupa del transport HTTP i no de les regles del negoci; i una regla al controlador es duplica tan bon punt apareix un segon punt d'entrada. I funcionen exactament igual que @Transactional (04-07): mitjançant un proxy que avalua l'expressió abans de delegar en l'objecte real. D'aquí, tres conseqüències que ja coneixem:

L'autoinvocació esquiva la seguretat, igual que esquiva la transacció. És la mateixa trampa de 04-07 i aquí és pitjor, perquè el símptoma no és una transacció que no s'obre: és una comprovació de permisos que no s'executa. Les sortides són les mateixes: extreure el mètode a un altre bean —l'opció neta—, injectar el proxy d'un mateix amb @Lazy, o replantejar el disseny.

Les altres dues conseqüències del model de proxies: els mètodes private, static i final no es poden interceptar —una anotació sobre un mètode privat s'ignora en silenci, sense cap avís—, i el bean ha de ser gestionat per Spring; un objecte creat amb new no té proxy ni seguretat.

La seguretat de l'aplicació no s'acaba en l'autenticació i l'autorització. Aquests són els punts que falten, cadascun amb la seva configuració concreta.

ConfiguracioCors (03-02) permet http://localhost:5173 perquè el frontend de l'equip funcioni en desenvolupament. Aquell origen no ha d'existir en producció.

Dos recordatoris: allowedOrigins("*") juntament amb allowCredentials(true) està prohibit per l'especificació i Spring ho rebutja en arrencar; i CORS no és un mecanisme de seguretat del servidor, sinó una política que aplica el navegador —curl la ignora—. Restringir CORS protegeix els teus usuaris de pàgines malicioses; no protegeix la teva API.

Sense límit de peticions, un sol client pot saturar l'API o provar contrasenyes sense descans. Les opcions, de fora cap a dins:

La recomanació és limitar a la passarel·la i deixar a l'aplicació només les regles que necessiten context, com «cinc intents d'inici de sessió per minut i correu». Amb Bucket4j:

Tres advertiments. El ConcurrentHashMap no serveix amb diverses instàncies —cada rèplica tindria el seu comptador— ni evita créixer sense límit: en producció, Redis (09-02). La clau s'ha de triar amb cura: per IP castiga tots els usuaris darrere d'una mateixa NAT; per usuari autenticat és més just, però no protegeix l'inici de sessió, on encara no hi ha usuari. I l'estat correcte és 429 amb Retry-After, perquè el client sàpiga quan reintentar.

Un cos enorme o una capçalera monstruosa són una manera barata de denegació de servei.

max-http-request-header-size mereix una nota: el valor per defecte de 8 KB n'hi ha ben bé prou per a un JWT de CicloUrbana, però amb tokens grans d'un proveïdor extern —amb molts claims— pot quedar-se curt i produir un 431 Request Header Fields Too Large difícil de diagnosticar. Apuja'l amb criteri, no «per si de cas».

Sense TLS, tot el mòdul és paper mullat: el token viatja llegible per la xarxa i qualsevol que sigui a la mateixa wifi el captura. L'habitual és terminar TLS al balancejador o l'ingress, però si l'aplicació ho fa directament:

I per rebutjar qualsevol petició que arribi sense xifrar, més HSTS (05-02):

Quan TLS acaba en un proxy, l'aplicació veu peticions HTTP i requiresSecure() produiria un bucle de redireccions. La solució és que el proxy enviï les capçaleres X-Forwarded-* i activar server.forward-headers-strategy: framework.

Cada dada que l'API revela sobre si mateixa facilita buscar un exploit conegut.

I la llista del que no ha de ser accessible en producció:

Tot això es governa amb perfils, el mecanisme que s'estudia a 07-02. La regla és que el perfil prod no hereti res perillós del de desenvolupament, i la comprovació pràctica és llançar l'aplicació amb --spring.profiles.active=prod i verificar que /swagger-ui.html respon 404.

Revisant 03-06 amb ulls de seguretat, un error pot regalar informació valuosíssima: noms de taules, rutes del sistema de fitxers, versions de llibreries, l'estructura interna del codi.

El GestorGlobalExcepcions de 03-06 ja ho fa bé: missatges controlats, codi propi i un identificador de rastreig que permet al suport trobar el detall al log del servidor, no a la resposta.

Tanquem el cercle obert a 05-01, ara amb noms concrets del projecte:

Dues observacions que resumeixen el mòdul. La primera: la meitat d'aquestes mitigacions no són de Spring Security. Els DTO de 03-05, les consultes parametritzades de 04-06 i les restriccions de 04-08 protegeixen tant o més que la cadena de filtres. Bona arquitectura i seguretat són en gran manera el mateix.

La segona: la injecció SQL mereix una nota concreta, perquè és el risc la protecció del qual es perd amb més facilitat. Aquests dos casos semblen equivalents i no ho són:

I hi ha un detall que sorprèn: el nom d'una columna en un ORDER BY dinàmic no es pot parametritzar. Si algú construeix l'ordenació concatenant un paràmetre de la petició, allà hi ha una injecció. La defensa és una llista blanca de columnes ordenables, no un intent d'escapament.

Spring Security publica esdeveniments d'aplicació a cada intent d'autenticació, i escoltar-los costa molt poc:

Advertiment. Un token o una contrasenya en un log és una credencial en un log, i els logs es copien a sistemes d'agregació, s'envien a tercers i es conserven anys. Quan algú detecta la fuita, aquella credencial fa mesos que circula. Revisa també les llibreries: alguns clients HTTP registren les capçaleres completes en DEBUG.

El tractament de logs en profunditat —format estructurat, agregació, retenció— es veu a 09-05, i l'alerta automàtica davant d'un pic de fallades, a 09-04.

Una aplicació arrossega desenes de dependències transitives, i una vulnerabilitat crítica en qualsevol d'elles és una vulnerabilitat de CicloUrbana. OWASP Dependency-Check compara l'arbre de dependències amb la base pública de vulnerabilitats:

Quatre consells pràctics. Executa'l a la integració contínua, no a mà, amb failBuildOnCVSS perquè una vulnerabilitat alta trenqui la construcció (mòdul 8). Hi haurà falsos positius: gestiona'ls amb un fitxer de supressions documentat, un per un i amb justificació, mai abaixant el llindar. Actualitzar la versió de Spring Boot és la via més eficaç, perquè l'starter-parent arrossega desenes de versions coherents de cop, amb atenció especial al que no gestiona, com el JJWT de 05-04. I subscriu-te als avisos de seguretat de Spring: una vulnerabilitat coneguda s'explota massivament poques hores després de publicar-se.

Advertiment final, i el més important del mòdul. Aquesta llista és necessària i no és suficient. Tot el que hem construït en aquestes cinc lliçons és un punt de partida didàctic: cobreix els errors més comuns, però no substitueix una revisió professional. Abans d'exposar un servei real —i més si maneja dades personals de ciutadans, com CicloUrbana— la configuració ha de ser revisada per un especialista en seguretat i sotmesa a una prova de penetració per algú que no hagi escrit el codi. La seguretat no és un estat que s'assoleix: és un procés que es manté, amb revisions periòdiques, actualitzacions i atenció als avisos.

Posar @PreAuthorize al controlador. Deixa el servei desprotegit davant de qualsevol altre punt d'entrada: tasques programades, consumidors de missatges o un endpoint nou.

Anotar un mètode private o cridar-lo des de la mateixa classe. El proxy no hi intervé i la comprovació no s'executa, sense cap avís. És la trampa de 04-07 amb conseqüències pitjors.

Fer servir @PostFilter sobre resultats paginats. Trenca la paginació i porta tota la taula a memòria. Filtra a la consulta.

@PostAuthorize en un mètode que escriu. L'efecte ja ha passat; el rollback de la transacció no desfà un correu enviat ni un càrrec fet.

Escriure SpEL complex dins de l'anotació. No es compila, no es prova i ningú no l'entén: extreu-ne un bean de seguretat. I recorda que SpEL no el comprova el compilador, així que hasRole('OPERRARI') arrenca sense protestar i denega sempre; aquestes expressions necessiten proves (mòdul 6).

Confiar en CORS com a mecanisme de seguretat. L'aplica el navegador; curl l'ignora. I no registris mai tokens ni contrasenyes «només en DEBUG»: els logs es copien i es conserven anys.

Consell: escriu la regla de seguretat i la seva prova alhora. Una regla sense prova és una hipòtesi, i el mòdul 6 comença precisament per aquí.

Consell: revisa la seguretat com revises el codi. Un canvi a ConfiguracioSeguretat, a un @PreAuthorize o a un DTO mereix la mateixa atenció que un canvi a la lògica de cobrament.

IncidenciaService gestiona les avaries de la flota de Ribalta. Aplica-hi seguretat de mètode amb aquests requisits, justificant cada anotació:

1. Qualsevol ciutadà autenticat pot crear una incidència sobre una bicicleta.
2. Només un OPERARI pot tancar una incidència.
3. Un ciutadà pot consultar les incidències que ell mateix va crear; un operari, qualsevol.
4. Només un ADMIN pot esborrar una incidència.
5. El llistat paginat ha de retornar a cada ciutadà només les seves, i a un operari totes.

Aquesta classe té cinc problemes de seguretat. Troba'ls, explica l'impacte de cadascun i reescriu-la.

L'ajuntament desplegarà CicloUrbana en producció la setmana que ve. Redacta l'informe de les deu comprovacions que faries, ordenades per criticitat, indicant per a cadascuna com la verificaries de manera objectiva.

Solució 1

Justificacions. El punt 1 fa servir isAuthenticated() i no hasRole('CIUTADA'), perquè un operari també ha de poder reportar; i l'autor es pren del principal perquè ningú no pugui crear incidències a nom d'un altre. El punt 3 és l'única regla que depèn de la dada i per això necessita un bean, SeguretatIncidencies, amb la mateixa forma que SeguretatLloguers. El punt 5 és el més instructiu: la decisió de quina consulta executar és una decisió de seguretat, i prendre-la a la consulta —en lloc de amb @PostFilter— és l'únic compatible amb paginació. El mètode esOperari() d'UsuariAutenticat encapsula la comprovació de l'autoritat ROLE_OPERARI, que altrament es repetiria per tot el projecte.

Solució 2

Problema 1 — retorna l'entitat Usuari. La resposta inclou contrasenyaHash, els rols i qualsevol camp que s'hi afegeixi en el futur: és exposició excessiva de dades, la fallada que va motivar els DTO de 03-05.

Problema 2 — IDOR a obtenir. No hi ha cap comprovació de permís: qualsevol autenticat —o qualsevol, si la regla per URL fallés— llegeix la fitxa de qualsevol ciutadà canviant l'id. És el risc A01/BOLA.

Problema 3 — injecció SQL a cercar. El paràmetre nom es concatena en una consulta nativa. Amb nom = ' OR '1'='1 es retornen tots els usuaris; amb una càrrega útil més elaborada, es poden executar altres sentències.

Problema 4 — @PreAuthorize sobre un mètode private. El proxy no el pot interceptar: l'anotació s'ignora en silenci i el mètode queda sense protecció. A més, un mètode privat no pot ser un gestor de Spring MVC.

Problema 5 — mass assignment a actualitzar. Rep l'entitat completa, així que la petició pot canviar rols, contrasenyaHash, actiu o fins i tot l'id. Un ADMIN compromès —o un error— pot reescriure qualsevol camp.

El controlador queda reduït a transport: tres mètodes public que reben @PathVariable, @RequestParam validats i @Valid @RequestBody ActualitzarUsuariRequest, retornen UsuariResponse o PaginaResponse<UsuariResponse> i deleguen en el servei, on viuen ara totes les regles:

ActualitzarUsuariRequest conté només nom i tipusTarifa: ni rols, ni contrasenya, ni actiu, ni id. Aquest és el punt: el que no és al DTO no es pot modificar, i el canvi de rols viu al seu propi endpoint amb les seves pròpies regles (exercici 3 de 05-03).

Solució 3

Criteri d'ordenació: primer el que compromet tot el sistema de cop (un secret filtrat, trànsit sense xifrar), després el que compromet dades de tercers (denegació per defecte, accés creuat), després el que facilita l'atac (documentació oberta, fuites als errors) i per últim el preventiu. I una observació sobre la número 1 que s'oblida sempre: un secret que va ser en un commit i després es va esborrar continua sent a l'historial de Git, així que esborrar-lo no basta: cal rotar-lo.

El mòdul 5 es tanca amb la xarxa de Ribalta protegida de dalt a baix. Has entès per què les regles per URL de 05-02, tot i ser necessàries, no basten: no poden expressar regles que depenen de la dada, no cobreixen els punts d'entrada que encara no existeixen i deixen la protecció lluny del codi que protegeixen. La seguretat de mètode és la capa que completa la perimetral, i ara saps triar entre les seves anotacions amb criteri: @PreAuthorize com a opció per defecte, @PostAuthorize només quan el permís depèn del resultat i mai sobre mètodes que escriuen, @PostFilter pràcticament mai —perquè porta tota la taula a memòria i trenca la paginació de 04-05— i @Secured o @RolesAllowed únicament en codi heretat. Domines el vocabulari SpEL —hasRole, principal, #parametre, @bean.metode(...)— i el seu gran advertiment: no el comprova el compilador, així que una regla mal escrita arrenca sense protestar i denega sempre.

Has tancat el forat amb què començava aquest mòdul mitjançant SeguretatLloguers.esPropietari, un bean llegible, comprovable, reutilitzable i eficient, i saps que les anotacions viuen al servei i funcionen amb proxies, amb la mateixa trampa d'autoinvocació de @Transactional i una conseqüència pitjor: la comprovació que no s'executa no avisa. I has endurit l'API punt per punt: CORS sense localhost en producció i sense la il·lusió que CORS protegeixi el servidor, limitació de taxa amb 429 i Retry-After, mides màximes de petició, HTTPS obligatori amb HSTS i X-Forwarded-*, Swagger i Actuator tancats fora de desenvolupament, errors que no filtren res, la taula OWASP amb la mitigació concreta de cada risc —inclosa la nota sobre l'ORDER BY dinàmic que cap paràmetre no pot protegir—, l'auditoria d'esdeveniments amb la seva llista del que no es registra mai, la revisió de dependències amb Dependency-Check i una llista de vint comprovacions l'últim punt de la qual és el més important: això és un punt de partida didàctic i necessita la revisió d'un professional de seguretat i una auditoria independent abans d'exposar-se a Internet.

CicloUrbana té per fi portes, panys i un registre de qui entra per cadascuna. Però hi ha una pregunta incòmoda que travessa tot el que hem construït i que fins ara hem respost amb curl i bona voluntat: com sabem que funciona? Ningú no ha comprovat automàticament que un ciutadà no pugui finalitzar el lloguer d'un altre, que anyRequest().denyAll() tanqui de debò el que ens pensem, que el token caduqui als quinze minuts o que la migració V4 deixi l'esquema tal com esperem. Cada canvi futur —un @PreAuthorize retocat, una regla reordenada, una dependència actualitzada— pot trencar en silenci qualsevol d'aquestes garanties, i ho descobriríem en producció. El mòdul 6, Proves a Spring Boot, ho resol: veurem la piràmide de proves i què val la pena provar, escriurem proves unitàries amb JUnit 5 i dobles amb Mockito, proves d'integració amb @SpringBootTest, @WebMvcTest i @DataJpaTest —incloses les de seguretat amb @WithMockUser, que convertiran en assercions automàtiques cada regla d'aquest mòdul— i aixecarem un PostgreSQL real i efímer amb Testcontainers per comprovar que Flyway, les entitats i les consultes es comporten igual que a Ribalta. La xarxa de Ribalta està protegida; ara cal demostrar-ho.