Com activar una Content Security Policy sense trencar el checkout del teu e-commerce

Una Content Security Policy, o CSP, ajuda a definir quins recursos pot carregar o executar el navegador en visitar una pàgina. Per a una empresa, el repte no sol ser entendre'n la finalitat, sinó aplicar-la sense interrompre un pagament, un formulari, l'analítica, el xat o qualsevol integració que sostingui l'operativa diària. Una política aplicada de manera brusca pot convertir una mesura defensiva en una incidència comercial.

La manera prudent d'implantar una CSP és tractar-la com un procés de control de dependències: saber quin servei carrega cada recurs, per què és necessari, qui l'aprova i en quines pàgines ha de funcionar. Aquest enfocament permet avançar per fases, començar pels recorreguts crítics i reduir autoritzacions innecessàries sense assumir que una configuració genèrica servirà per a tots els webs.

El problema: dependències invisibles en pàgines crítiques

En un web corporatiu o una botiga en línia, el navegador pot carregar scripts, imatges, connexions i marcs de nombrosos proveïdors. Alguns responen a necessitats clares, com ara una passarel·la de pagament o un mapa; d'altres poden procedir d'un plugin antic, una etiqueta de campanya temporal o una eina que ningú no revisa des de fa temps. El problema concret és perdre visibilitat sobre aquestes dependències i autoritzar més del necessari per por que alguna cosa deixi de funcionar.

La capçalera HTTP Content-Security-Policy permet indicar de quines fonts pot carregar o executar recursos una pàgina. Pot contribuir a mitigar determinats atacs d'injecció de contingut i XSS, però cal adaptar-la a cada lloc i a les seves integracions reals. Per tant, no convé començar enganxant una política trobada en un altre web: el punt de partida ha de ser el comportament autoritzat de la mateixa aplicació. [2]

• Prioritzeu l'inici de sessió, l'àrea de client, els formularis, el carretó i el checkout.
• Registreu cada tercer amb el seu domini, funció, pàgines afectades i responsable intern.
• Incloeu les connexions amb CRM, ERP o altres API utilitzades des del navegador.

Què cobreix una CSP i quins són els seus límits

Una CSP actua al navegador que renderitza HTML: pot limitar, entre altres elements, els scripts que s'executen, les connexions sortints, les imatges, els formularis i els llocs que poden incrustar una pàgina. Directives com script-src, connect-src, img-src, form-action, base-uri i frame-ancestors han de respondre a una necessitat concreta, no a una recepta universal. [2] [3]

No substitueix la correcció de vulnerabilitats, la validació d'entrades, la codificació de sortida ni la revisió del codi. OWASP situa la CSP com una defensa addicional davant d'XSS, no com a reemplaçament de les mesures principals. Tampoc no fa segur un proveïdor extern només per incloure'n el domini en una llista permesa; cada autorització continua sent una decisió de risc i d'operativa. [1]

• Eviteu aprovar dominis amb comodins o «per si de cas».
• No normalitzeu unsafe-inline o unsafe-eval com a solució permanent.
• Quan l'arquitectura ho permeti, valoreu nonces per resposta o hashes per autoritzar scripts concrets.

Primer inventariar i observar, després bloquejar

Abans d'imposar restriccions, prepareu un inventari per plantilla o recorregut de negoci. Distingiu, per exemple, la pàgina de producte, l'accés al compte i el checkout. Una passarel·la pot requerir recursos que no apareixen a la resta del web, i una política separada per a aquesta zona pot ser més manejable que una excepció àmplia aplicada a tot el domini. Feu les proves només en entorns i sistemes per als quals existeixi una autorització expressa.

El mode Content-Security-Policy-Report-Only permet rebre avisos d'incompliment sense bloquejar encara els recursos. És útil per identificar dependències durant una finestra que cobreixi l'ús real: campanyes actives, pagaments, registres, formularis i dispositius diferents. Els avisos no són una llista automàtica de dominis que s'hagin d'aprovar; són material per investigar, classificar i decidir. [4]

• Assigneu un responsable a la revisió de cada incompliment.
• Diferencieu els recursos legítims, les dependències obsoletes i els comportaments desconeguts.
• Conserveu una política validada a la qual tornar mitjançant un procediment de reversió autoritzat.

Definir regles mínimes i protegir els informes

Després de revisar els avisos, permeteu únicament els orígens necessaris per a cada funció. script-src regula els scripts; connect-src, les connexions iniciades pel navegador; img-src, les imatges; i form-action, les destinacions permeses per a l'enviament de formularis. frame-ancestors mereix una comprovació específica: controla quins llocs poden mostrar la pàgina en un iframe, de manera que abans cal confirmar si existeixen portals, suport o altres incrustacions legítimes. [2]

Els informes de CSP també requereixen controls. Poden contenir dades no fiables, per la qual cosa s'han de validar i sanejar abans d'emmagatzemar-los, mostrar-los en un panell o emprar-los en automatitzacions. Eviteu que un informe generi per si sol una excepció en la política: tota modificació necessita revisió humana, un propietari i una justificació tècnica i operativa. [5]

• Documenteu el motiu i la data de cada origen aprovat.
• Proveu el pagament complet, la recuperació de contrasenya, l'enviament de formularis i les confirmacions.
• Si un tercer canvia els seus dominis o recursos, torneu a avaluar-ne la necessitat abans d'ampliar permisos.

Pas a producció i manteniment continu

El pas al mode d'aplicació s'ha de fer gradualment i amb verificació funcional. En un exemple hipotètic, una botiga pot activar primer la política a la zona de compte, confirmar que l'accés i la recuperació de contrasenya funcionen, i després incorporar el checkout després de provar el flux de pagament amb la passarel·la autoritzada. Si sorgeix un bloqueig crític, apliqueu la reversió documentada, registreu què ha passat i corregiu la regla o la dependència abans de tornar-ho a intentar.

La CSP s'ha d'integrar en el procés de canvi web. Un plugin nou, un píxel publicitari, un xat, un proveïdor de pagament o una automatització pot requerir recursos addicionals i ha de passar per revisió abans de publicar-se. Una auditoria de protecció web pot ajudar a ordenar aquest inventari, revisar configuracions i validar recorreguts autoritzats; no elimina la responsabilitat de mantenir la política alineada amb l'arquitectura i el negoci.

• Incloeu la revisió de CSP en les altes de proveïdors i els desplegaments.
• Retireu permisos quan s'elimini una integració.
• Reviseu periòdicament les pàgines crítiques i els canvis de tercers.

Preguntes freqüents

Una Content Security Policy evita tots els atacs XSS?

No. Pot reduir l'impacte de determinats escenaris d'injecció i XSS en limitar els recursos que el navegador accepta, però és una capa complementària. L'aplicació ha de continuar aplicant validació d'entrades, codificació de sortida, sanejament quan correspongui i revisió de codi.

He d'utilitzar la mateixa CSP a tot el web?

No necessàriament. Les pàgines poden tenir dependències diferents. El checkout, per exemple, pot necessitar recursos d'una passarel·la que no s'han d'autoritzar en una pàgina informativa. La decisió depèn de l'arquitectura i s'ha de provar en recorreguts autoritzats i representatius.

Què faig si el mode Report-Only genera molts avisos?

Classifiqueu-los abans de canviar la política. Identifiqueu la pàgina afectada, el recurs, el proveïdor, la funció i el responsable intern. Aproveu només el necessari, retireu dependències antigues quan sigui viable i tracteu les dades dels informes com a no fiables abans de visualitzar-les o automatitzar accions amb aquestes.