1. Definir què entra en la revisió

Fes un inventari del web públic, el tauler d’administració, les API, els formularis i les integracions que sostenen l’activitat. Identifica qui manté cada peça i quines dades tracta. Una botiga amb pagaments, un portal de clients i un web informatiu necessiten abasts diferents; el nombre de pàgines, tot sol, no descriu aquesta diferència.

Abans de començar, acorda per escrit dominis, entorns, comptes de prova, dates i límits. Inclou qui autoritza les comprovacions, com s’avisa d’una incidència i quan cal aturar-les. Els serveis de tercers requereixen comprovar-ne les condicions i els permisos; que apareguin al teu web no els converteix en part de l’abast autoritzat.

2. Demanar un mètode que es pugui explicar

OWASP WSTG recull una metodologia de proves per a aplicacions web. ASVS ofereix requisits per verificar controls de seguretat. Són referències per concretar la feina, no certificats que una empresa o un web siguin invulnerables. [1] [2]

Demana que la proposta indiqui quines àrees es revisaran i què en queda fora: configuració, autenticació, permisos, gestió de sessions, tractament d’entrades i funcions de negoci rellevants. La combinació d’eines i revisió manual ha de respondre a l’abast acordat. Una comprovació automàtica aïllada no permet afirmar que s’ha revisat cada flux de l’aplicació.

3. Revisar accessos i canvis amb context

Prepara una relació de perfils: visitant, client, empleat i administrador, quan existeixin. L’equip auditor ha d’entendre què pot fer cadascun. Una funció aparentment normal pot ser un problema si està disponible per a un perfil que no la necessita. Facilita comptes dedicats, evita compartir credencials personals i acorda retirar-los en acabar la feina.

La revisió també hauria de considerar com es mantenen el CMS, les extensions i les dependències. Pregunta qui aprova les actualitzacions, on es proven i com es torna a una versió anterior. Registrar una versió antiga és una dada útil; convertir-la en una prioritat exigeix conèixer-ne l’exposició, l’ús real i les mesures existents.

4. Exigir troballes que permetin actuar

Cada troballa hauria de descriure el component afectat, l’evidència mínima necessària, l’impacte possible, les condicions perquè es produeixi i una recomanació concreta. L’informe ha de protegir informació sensible: limita captures i dades de prova al que calgui i acorda qui tindrà accés al document i durant quant de temps.

Exemple hipotètic: si un compte amb permisos bàsics pot consultar un document reservat, l’informe ha d’explicar la separació de permisos esperada, l’observada i la correcció proposada. No cal copiar documents reals per demostrar el problema. El resum per a direcció ha de traduir la prioritat tècnica en una decisió entenedora, sense exagerar l’impacte.

5. Separar la correcció de la comprovació

Aclareix si el pressupost cobreix només l’auditoria, també les correccions o una comprovació posterior. Assigna a cada acció una persona responsable i una data acordada. Si hi intervenen el proveïdor d’allotjament i l’agència de desenvolupament, defineix qui coordina els canvis i qui confirma que no s’han alterat funcions essencials.

Tancar una tasca no demostra que el problema hagi desaparegut. Conserva evidència de la comprovació posterior i registra les limitacions pendents. Després de canvis importants en accessos, pagaments o integracions pot caldre revisar l’abast. L’auditoria descriu un estat i un moment; no substitueix el manteniment continu.

6. Preparar una primera conversa útil

Porta una descripció de l’activitat, les URL principals, la tecnologia coneguda, els proveïdors implicats i les dates que cal evitar. No enviïs contrasenyes ni bases de dades en el primer contacte. Explica què et preocupa: continuïtat del servei, permisos de clients, un canvi recent o falta de visibilitat sobre el manteniment.

Per treballar des de Barcelona amb equips d’altres països, acorda l’idioma de l’informe, els fusos horaris i un contacte operatiu. La proximitat ajuda a coordinar-se, però la qualitat depèn d’un abast precís, evidències clares i seguiment. Aquest és el criteri més útil per comparar propostes i convertir la revisió en una millora verificable.

Fonts primàries

  1. OWASP Web Security Testing Guide ↗
  2. OWASP Application Security Verification Standard ↗