El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Ja saps què és OWASP i d'on ve. Toca respondre a la pregunta que dona sentit a tot el curs: per què la seguretat de les aplicacions web és tan important? Si no interioritzes aquesta resposta, la seguretat et semblarà una càrrega burocràtica en lloc d'una necessitat. En aquesta lliçó veurem per què el web és un blanc tan atractiu, quant costa realment una bretxa, què protegim exactament (la tríada CIA), i per què la seguretat ha de ser una propietat transversal de tot el desenvolupament i no un pedaç final. Tot aterrat en el que BazarNube s'hi juga de veritat.

Nota: aquí veurem el perquè i el què. El com integrar-ho en el cicle de desenvolupament (l'SDLC segur) es tracta al mòdul 7; en aquesta lliçó només el presentem a alt nivell.

Contingut

Per què el web és un blanc: la superfície d'atac
El valor de les dades i el compliment normatiu
El cost real d'una bretxa de seguretat
La tríada CIA: què protegim exactament
La seguretat com a propietat transversal ("shift-left")
Què s'hi juga BazarNube

Per què el web és un blanc: la superfície d'atac

Una aplicació web és, per definició, pública: està exposada a internet perquè qualsevol usuari legítim la faci servir. El problema és que "qualsevol usuari" inclou també els atacants. A diferència d'un programa intern, la teva aplicació web és accessible 24/7 des de qualsevol punt del planeta.

Anomenem superfície d'atac el conjunt de punts pels quals un atacant pot intentar entrar o interactuar amb el sistema. Com més punts d'entrada, més gran és la superfície. Una aplicació web moderna en té molts:

Cada endpoint de l'API (rutes com /login, /productes, /pagaments).
Cada formulari i camp d'entrada del frontend.
Les capçaleres HTTP, les cookies i els tokens.
Les dependències de tercers (llibreries npm, paquets de Java...).
La infraestructura que l'allotja (contenidors, configuració del núvol).

graph LR
    ATK[Atacant<br/>des de qualsevol lloc] --> EP1[/login/]
    ATK --> EP2[/productes/]
    ATK --> EP3[/pagaments/]
    ATK --> DEP[Dependencies<br/>de tercers]
    ATK --> INFRA[Configuracio<br/>del nuvol]
    subgraph Superficie de atac de la aplicacio web
        EP1
        EP2
        EP3
        DEP
        INFRA
    end

La conseqüència pràctica és demolidora: n'hi ha prou que un sol d'aquests punts sigui vulnerable per comprometre tot el sistema. El defensor ha de protegir tots els punts; l'atacant només necessita trobar-ne un. Aquesta asimetria és la raó de fons per la qual la seguretat web és tan exigent.

El valor de les dades i el compliment normatiu

Els atacants no ataquen per esport (normalment): ataquen perquè hi ha alguna cosa valuosa per obtenir. I les aplicacions web custodien precisament això: dades.

Dades personals: noms, correus, adreces, telèfons. Serveixen per suplantar identitats, spam o revenda.
Credencials: usuaris i contrasenyes, que es reutilitzen en altres serveis.
Dades financeres: targetes, comptes, historials de pagament. L'objectiu més directe del frau.

Com que aquestes dades són sensibles, existeixen normatives que obliguen a protegir-les. No cal que les dominis ara (algunes es veuen en mòduls posteriors), però sí que les reconeguis a alt nivell:

Normativa	Què protegeix	A qui aplica (a grans trets)
GDPR / RGPD	Dades personals de ciutadans de la UE.	Qualsevol empresa que tracti dades d'europeus, sigui on sigui.
PCI-DSS	Dades de targetes de pagament.	Qualsevol empresa que emmagatzemi, processi o transmeti pagaments amb targeta.
HIPAA	Dades de salut (context EUA).	Entitats sanitàries i els seus proveïdors.

La conseqüència clau: la seguretat no és només una bona idea tècnica, és una obligació legal. Incomplir GDPR o PCI-DSS pot comportar multes quantioses i la pèrdua de la capacitat d'operar (per exemple, que el teu proveïdor de pagaments et retiri el servei).

El cost real d'una bretxa de seguretat

Quan una bretxa passa, el cost va molt més enllà d'"arreglar el bug". Convé veure-ho desglossat, perquè sovint només es pensa en la part tècnica, que sol ser la més petita:

Tipus de cost	Exemples
Directe / tècnic	Investigar l'incident, apedaçar, restaurar sistemes, contractar perits forenses.
Legal i regulatori	Multes (GDPR/PCI-DSS), demandes de clients afectats, obligació de notificar.
Reputacional	Pèrdua de clients, cobertura negativa a la premsa, caiguda de confiança.
Operatiu	Temps d'inactivitat, vendes perdudes, equip dedicat a apagar el foc en comptes de construir.
A llarg termini	Costos d'assegurances més alts, dificultat per captar inversió o clients.

Per a una startup el cop és especialment perillós: una empresa gran pot absorbir una multa i una crisi reputacional, però una startup jove pot no sobreviure a una bretxa greu. La confiança és el seu actiu més fràgil, i es perd en un dia.

La tríada CIA: què protegim exactament

Quan diem "protegir", què protegim? La seguretat de la informació es resumeix clàssicament en tres propietats, conegudes per les sigles en anglès com a CIA (res a veure amb l'agència): Confidentiality, Integrity, Availability.

Propietat	Què garanteix	Es trenca quan...	Exemple en un e-commerce
Confidencialitat	Que només qui està autoritzat accedeixi a la informació.	Un atacant llegeix dades que no hauria de veure.	Es filtra la base de dades de clients.
Integritat	Que la informació no s'alteri de manera no autoritzada.	Algú modifica dades sense permís.	Un atacant canvia el preu d'una comanda a 0 €.
Disponibilitat	Que el servei estigui accessible quan es necessita.	El sistema deixa de respondre.	Un atac tomba la botiga en plena campanya de rebaixes.

graph TD
    S[Seguretat de la<br/>informacio] --> C[Confidencialitat<br/>nomes acces autoritzat]
    S --> I[Integritat<br/>dades no alterades]
    S --> A[Disponibilitat<br/>servei accessible]

La tríada CIA és una eina d'anàlisi enormement útil: davant qualsevol risc, pregunta't quina de les tres propietats amenaça. Veuràs que gairebé tot encaixa en una (o diverses) d'elles. És un vocabulari que farem servir durant tot el curs i que connecta directament amb el model d'amenaces que construirem per a BazarNube.

Vegem-ho amb un fragment de codi. Aquest endpoint de l'API de BazarNube té un problema clàssic que compromet la confidencialitat i la integritat:

// API de BazarNube (Node.js + Express) - VERSIO INSEGURA
app.get('/api/comandes/:id', (req, res) => {
  // Es retorna la comanda demanada per id SENSE comprovar
  // si l'usuari autenticat n'es el propietari.
  const comanda = db.comandes.findById(req.params.id);
  res.json(comanda);
});

El problema: qualsevol usuari autenticat pot demanar /api/comandes/1, /api/comandes/2, etc., i llegir comandes alienes (trenca la confidencialitat). Falta comprovar la propietat del recurs. Una versió més segura seria:

// VERSIO MILLORADA: es verifica que la comanda pertany a l'usuari
app.get('/api/comandes/:id', requireAuth, (req, res) => {
  const comanda = db.comandes.findById(req.params.id);
  if (!comanda || comanda.usuariId !== req.user.id) {
    // No revelem si existeix o no: retornem 404 en tots dos casos
    return res.status(404).json({ error: 'No trobat' });
  }
  res.json(comanda);
});

Aquí requireAuth garanteix que hi ha un usuari autenticat, i la comprovació comanda.usuariId !== req.user.id garanteix que només veu les seves comandes. No et preocupis per dominar aquest patró ara: l'estudiarem a fons al mòdul 3 (control d'accés). L'objectiu aquí és que vegis com una decisió de codi concreta es tradueix en una propietat de la tríada CIA.

La seguretat com a propietat transversal ("shift-left")

Un error històric molt estès és tractar la seguretat com l'última fase abans de llançar: es construeix tot i, al final, es fa una revisió de seguretat "a veure si passa". Aquest enfocament falla per dos motius:

Les fallades ja estan cuites en el disseny. Molts problemes de seguretat neixen de decisions d'arquitectura preses al principi. Detectar-los al final significa refer, no apedaçar.
Arreglar tard és caríssim. Corregir una fallada en producció costa molt més —en temps i diners— que evitar-la en la fase de disseny.

L'alternativa es resumeix en una idea anomenada "shift-left" (desplaçar a l'esquerra): moure les consideracions de seguretat cap al principi del procés, no cap al final. Si imagines el cicle de desenvolupament com una línia d'esquerra (idea/disseny) a dreta (producció), "shift-left" significa pensar en seguretat des de l'extrem esquerre.

graph LR
    D[Disseny] --> C[Codificacio] --> T[Proves] --> P[Produccio]
    S[Seguretat com<br/>propietat transversal] -.-> D
    S -.-> C
    S -.-> T
    S -.-> P

Fixa't en les línies puntejades: la seguretat toca totes les fases, no una de sola. És una propietat transversal, com la qualitat o el rendiment: no és una cosa que "s'afegeix" al final, sinó una cosa que impregna cada decisió.

Aquí només introduïm la idea. Com s'organitza a la pràctica dins el cicle de vida del desenvolupament (l'SDLC segur, el modelatge d'amenaces, DevSecOps) és el tema del mòdul 7; de moment n'hi ha prou que interioritzis el principi: abans i durant, no només al final.

Què s'hi juga BazarNube

Apliquem-ho tot al nostre cas. Recorda: BazarNube és un marketplace amb dades de clients, pagaments i un mòdul legacy de facturació en Java. Junt amb Lucía, Marc i la SRE, comences a mapejar quins riscos concrets corre l'empresa, classificant-los amb la tríada CIA. Aquest és el germen del backlog de troballes que construirem al llarg del curs:

Actiu en risc	Què podria passar	Propietat CIA amenaçada	Impacte per a BazarNube
Base de dades de clients	Filtració de dades personals	Confidencialitat	Multa GDPR + pèrdua de confiança
Dades de pagament	Robatori de dades de targetes	Confidencialitat	Sanció PCI-DSS + frau als clients
Preus i comandes	Manipulació de l'import a pagar	Integritat	Pèrdues econòmiques directes
Disponibilitat de la botiga	Caiguda durant una campanya	Disponibilitat	Vendes perdudes + dany reputacional
Mòdul legacy en Java	Vulnerabilitat sense apedaçar	Confidencialitat / Integritat	Porta d'entrada a la resta del sistema

Per a una startup com BazarNube, les tres conseqüències més temudes es resumeixen així:

Dades de clients: una filtració destruiria la confiança que tant costa guanyar.
Pagaments: un incident amb targetes implicaria sancions i podria deixar-los sense proveïdor de pagaments.
Reputació: en un mercat competitiu, "la botiga a qui van piratejar" és una etiqueta que espanta clients i inversors.

Amb aquest mapa inicial, l'equip entén que la seguretat no és opcional ni cosmètica: és una condició per sobreviure i créixer. I ara té la motivació per endinsar-se en les eines concretes d'OWASP.

Errors Comuns i Consells

Pensar "a mi no m'atacaran". Els atacs avui són en gran mesura automatitzats: bots rastregen internet buscant qualsevol aplicació vulnerable, sense que importi la mida de l'empresa. Ser petit no et fa invisible, et fa un blanc fàcil.
Reduir la seguretat a la confidencialitat. Molta gent només pensa en "que no robin dades". Integritat i disponibilitat són igual d'importants: un preu manipulat o una botiga caiguda també són incidents greus.
Deixar la seguretat per al final. És l'error més car. Aplica el principi "shift-left": pensa en seguretat des del disseny.
Ignorar el compliment fins que "toqui". GDPR i PCI-DSS apliquen des del primer client, no quan ets gran. Ignorar-los al principi crea un deute que esclata en el pitjor moment.
Consell: davant qualsevol funcionalitat nova, pregunta't: "quina propietat de la CIA posa en risc i qui voldria atacar-la?". És el primer pas del modelatge d'amenaces.

Exercicis

Exercici 1. Per a cada incident, indica quina propietat de la tríada CIA es veu compromesa principalment: (a) un atacant descarrega la llista de correus de tots els clients; (b) un atacant modifica el saldo del seu moneder a la botiga; (c) un atac massiu deixa el web inaccessible durant hores.

Exercici 2. BazarNube va a afegir una funció d'"exportar les meves comandes a PDF". Abans de programar-la, aplica el principi "shift-left": enumera almenys dues preguntes de seguretat que us hauríeu de fer en la fase de disseny (no al final).

Exercici 3. Explica, en 4-6 línies, per què una bretxa de seguretat pot ser més perillosa per a una startup com BazarNube que per a una gran corporació, fent servir almenys dos dels tipus de cost vistos a l'apartat 3.

Solucions

Solució 1. (a) Confidencialitat (s'accedeix a dades que haurien de ser privades); (b) Integritat (s'alteren dades —el saldo— sense autorització); (c) Disponibilitat (el servei deixa d'estar accessible).

Solució 2. Exemples de preguntes de disseny (n'hi ha prou amb dues):

Com garantim que un usuari només pot exportar les seves comandes i no les d'un altre? (control d'accés, confidencialitat).
El PDF podria incloure dades sensibles (com dades de pagament) que no haurien d'aparèixer? (minimització de dades).
La generació del PDF es podria abusar per saturar el servidor si algú la invoca en massa? (disponibilitat).
On s'emmagatzema temporalment el PDF i qui hi pot accedir? Plantejar això abans de codificar evita refer la funció més tard.

Solució 3. Una gran corporació pot absorbir els costos legals i regulatoris (una multa) i els costos reputacionals (una crisi d'imatge) gràcies a la seva mida, les seves reserves i la seva base de clients consolidada. Una startup com BazarNube, en canvi, depèn críticament de la confiança dels seus primers clients i inversors: un dany reputacional pot provocar una fuga massiva d'usuaris, i un cost operatiu elevat (aturada de vendes, equip apagant focs) pot esgotar la seva escassa tresoreria. La suma la pot portar directament al tancament, cosa molt menys probable en una empresa gran.

Conclusió

En aquesta lliçó has entès per què la seguretat web és crítica: una aplicació pública té una superfície d'atac enorme i asimètrica, custodia dades valuoses subjectes a normatives com GDPR i PCI-DSS, i una bretxa comporta costos tècnics, legals, reputacionals i operatius que poden enfonsar una startup. Has incorporat la tríada CIA (confidencialitat, integritat, disponibilitat) com a eina per classificar riscos, i el principi "shift-left": la seguretat és una propietat transversal, no una fase final. I has traçat el primer mapa de riscos de BazarNube, el germen del backlog que anirem ampliant.

Amb això tanquem el mòdul 1. Ja saps què és OWASP, d'on ve i per què la seguretat importa. Al mòdul 2 passarem de la teoria a la caixa d'eines: recorrerem els principals projectes d'OWASP —començant pel cèlebre OWASP Top Ten, la llista dels deu riscos més crítics— per començar a posar nom concret a les amenaces que avui només hem esbossat per a BazarNube.

Importància de la Seguretat en Aplicacions Web

Contingut

Per què el web és un blanc: la superfície d'atac

El valor de les dades i el compliment normatiu

El cost real d'una bretxa de seguretat

La tríada CIA: què protegim exactament

La seguretat com a propietat transversal ("shift-left")

Què s'hi juga BazarNube

Errors Comuns i Consells

Exercicis

Solucions

Conclusió

Curs d'OWASP: Directrius i Estàndards per a la Seguretat en Aplicacions Web

Mòdul 1: Introducció a OWASP

Mòdul 2: Principals Projectes d'OWASP

Mòdul 3: OWASP Top Ten 2021 en Profunditat

Mòdul 4: OWASP ASVS (Application Security Verification Standard)

Mòdul 5: OWASP SAMM (Software Assurance Maturity Model)

Mòdul 6: OWASP ZAP (Zed Attack Proxy)

Mòdul 7: Bones Pràctiques i Recomanacions

Mòdul 8: Exercicis Pràctics i Casos d'Estudi

Mòdul 9: Avaluació i Certificació