Seguretat dels pagaments: què no has de desar mai i per què se signen els webhooks

Acceptar targetes obliga a complir l'estàndard PCI DSS. La bona notícia és que la major part d'aquest compliment es pot delegar: si el teu servidor no veu mai un número de targeta, gairebé tota la feina se l'endú el teu proveïdor. La dolenta és que hi ha dues maneres fàcils d'espatllar-ho.

Dades que no pots desar, ni xifrades

L'estàndard distingeix entre dades que es poden emmagatzemar amb protecció i dades que no es poden emmagatzemar mai després d'autoritzar el pagament:

• El codi de verificació de tres o quatre dígits del revers o l'anvers.
• El contingut complet de la banda magnètica o del xip.
• El PIN o el seu bloc xifrat.

Xifrar-les no ho arregla: la prohibició és sobre l'emmagatzematge, no sobre el format. El número de targeta sí que es pot desar sota condicions estrictes, però la pregunta correcta gairebé sempre és una altra: per a què el vols? Si és per a cobraments recurrents, el que necessites és un token, no el número.

SAQ A: l'objectiu raonable per a gairebé tothom

El qüestionari d'autoavaluació més lleuger, conegut com a SAQ A, està pensat per a comerços que externalitzen completament la captura de dades de targeta: el formulari el serveix el proveïdor de pagament dins d'un iframe o mitjançant redirecció, i la teva pàgina no toca mai el número.

La diferència pràctica és enorme: passes d'haver de protegir, segmentar i auditar la teva pròpia infraestructura a respondre un qüestionari curt. La contrapartida és que el formulari deixa de ser teu, amb les limitacions de disseny que això implica, i que qualsevol drecera —capturar el número «només un moment» per reenviar-lo— et treu d'aquest règim sense avisar.

Tokens: dues coses diferents amb el mateix nom

• Un token del proveïdor substitueix el número de targeta dins del teu sistema. Serveix per tornar a cobrar sense tornar a demanar la targeta, però només funciona amb aquell proveïdor.
• Un token de xarxa, el que hi ha darrere d'Apple Pay o Google Pay, l'emet la mateixa xarxa de targetes i va acompanyat d'un criptograma que canvia a cada operació. Si algú l'intercepta, no li serveix de res.

En tots dos casos la idea és la mateixa: la dada sensible deixa de circular. És la mateixa lògica que fa que un permís d'accés hagi de viure al teu servidor i no al mòbil, com s'explica a pagaments dins d'apps.

Per què se signen els webhooks

Quan un pagament es completa, el navegador del client torna al teu web amb una URL de retorn. Aquesta URL no és una font fiable: la controla el client, i qualsevol la pot visitar. Si el teu sistema marca la comanda com a pagada perquè el navegador ha tornat a `/gracies`, tens un problema de seguretat, no un detall d'implementació.

La font fiable és el webhook: una crida de servidor a servidor des del teu proveïdor de pagaments, signada. La signatura habitual és un HMAC-SHA256 del cos exacte del missatge amb un secret compartit, enviat en una capçalera. Verificar-ho bé té quatre regles:

• Signar i verificar sobre el cos en cru, abans de parsejar el JSON. Un reordenament de claus canvia la signatura.
• Comparar en temps constant, no amb una comparació de cadenes normal.
• Comprovar l'antiguitat del missatge si ve amb marca de temps, perquè una petició capturada no valgui mesos després.
• Ser idempotent: el mateix esdeveniment pot arribar diverses vegades. Processar-lo dues vegades no ha de concedir dues vegades l'accés ni emetre dues factures.

I una regla més: si la signatura no valida, la resposta correcta és un error, no un «el processo igualment per si de cas».

L'import el decideix el servidor

L'últim clàssic: acceptar l'import que arriba des del client. Un formulari, un paràmetre a la URL o un camp ocult són editables. L'import a cobrar ha de sortir sempre del catàleg al servidor; el que envia el client és, com a molt, la referència del producte. Les tres fases del cobrament —i on encaixa cada validació— estan descrites a com funciona un cobrament amb targeta.

Registres: menys és més

Els sistemes de pagament generen molts registres, i allà acaben filtrant-se dades per descuit: capçaleres de signatura completes, cossos de webhook sense retallar, correus i adreces en text pla. Registra identificadors i estats, no continguts, i defineix quant de temps es conserven. Un registre que ningú consulta i ningú esborra és només superfície d'atac.

En resum

La seguretat d'un cobrament es juga en decisions avorrides: no desar el que no necessites, no creure't el navegador, verificar signatures com cal i ser idempotent. Res d'això és visible per al client, i tot es nota el dia que alguna cosa va malament. Pots veure la resta d'articles sobre seguretat i normativa o com es representen els estats d'un pagament a la demo.