Què indica un 401 o 403: el servei extern ha arribat a una URL, però alguna capa ha rebutjat la petició. La resposta pot venir de WordPress, d’autenticació bàsica, del servidor web, del CDN, del WAF o de la pròpia validació de signatura del webhook.
Localitza primer qui genera la resposta
Guarda URL, mètode HTTP, codi, capçaleres de resposta i cos retornat. Les capçaleres i els registres del servidor solen permetre separar un bloqueig del WAF d’un rebuig de WordPress o d’un secret incorrecte.
No confonguis autenticació amb filtratge de trànsit
Si falta la capçalera de signatura o el secret no coincideix, obrir el tallafoc no resoldrà res. I si el WAF bloqueja la petició abans d’arribar a PHP, regenerar el secret tampoc canviarà el 403.
Comprovacions que aporten evidència
- Verifica l’endpoint exacte configurat al proveïdor.
- Comprova secret, algorisme de signatura i entorn actiu.
- Revisa si el proxy conserva
Authorizationi les capçaleres de signatura. - Consulta regles de WAF, autenticació bàsica i manteniment només per a aquesta ruta.
Correcció segura segons la causa
- Si el secret és incorrecte, rota’l deliberadament als dos extrems.
- Si el proxy elimina capçaleres, conserva només les necessàries per a l’endpoint.
- Si és el WAF, crea una excepció mínima per ruta, mètode i comportament esperat.
- Reprodueix un únic esdeveniment signat i comprova l’efecte final a WooCommerce.
Relaciona el 401/403 amb el símptoma de negoci
Un 401 o 403 pot explicar que Stripe no actualitzi una comanda; tens el flux específic a webhook de Stripe que no actualitza l’estat. Si el problema és PayPal, compara’l amb pagament de PayPal completat però comanda sense actualitzar.
Què no has d’obrir per “fer que funcioni”
No eliminis la verificació de signatura ni exposis l’endpoint a qualsevol petició només per obtenir un 200. La reparació correcta accepta els esdeveniments autèntics i continua rebutjant signatures incorrectes i trànsit aliè.
Verificació final
La incidència queda tancada quan un esdeveniment vàlid arriba, retorna èxit i modifica l’ordre una sola vegada, mentre que una petició no signada o manipulada continua sent rebutjada i queda registrada.
CRITERI D’INCIDENT WP REPAIR
Reconstrueix la incidència abans de corregir-la
Llistat blanc de tot el tràfic d'un proveïdor sense confirmar la font de resposta pot debilitar el lloc i encara deixar secrets invàlids.
- 1
Registra la crida de retorn URL, mètode, capçaleres, cos de la resposta i servei font.
- 2
Determini quina capa va generar el 401/4003 de les capçaleres i registres.
- 3
Verifica el secret webhook, l’algorisme de signatura i la configuració d’endpoint.
- 4
Comprova les regles WAF, anàlisi bàsica i manteniment per a la ruta exacta.
Què ha de quedar verificat
- Els esdeveniments signats vàlids retornen l’èxit.
- Les signatures no vàlides i les sol·licituds no relacionades continuen sent rebutjades.
- L'estat de la comanda canvia una vegada per esdeveniment i és visible en registres.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
Si faig una llista blanca del rang IP del proveïdor de pagaments, això corregirà el 401/403?+
No és fiable, i pot debilitar la seguretat. Llistat blanc de tot el trànsit d’un proveïdor sense confirmar quina capa realment va generar el rebuig pot deixar secrets invàlids en el seu lloc mentre s'amplia el que està permès a través del seu tallafocs innecessàriament.
Com sé si el 401/403 ve de WordPress o d'un WAF/proxy davant d'ell?+
Determinar quina capa va generar la resposta mitjançant l'examen de les capçaleres de resposta i registres en cada capa: WordPress, auth bàsica, un WAF, una política d'accés CDN i la verificació de la signatura poden produir independentment un 401 o 403, i la solució difereix depenent de quin és responsable.
És acceptable eliminar l’autenticació en l’endpoint webhook perquè deixi de tornar errors?+
No, això s'adverteix explícitament en contra. Exposar una ruta webhook sense verificar de signatura simplement per obtenir una resposta de 200 elimina el xec que confirma peticions genuïnament provenint del proveïdor de pagaments, trading un error visible per un forat de seguretat ocult.
Quina és la manera més segura de confirmar que una solució realment funciona abans de confiar en la producció?+
Torna a reproduir un esdeveniment de prova signat a través de la configuració corregida i confirma els canvis d’estat d’ordre WooCommerce resultants correctament, en comptes d’assumir que una correcció funciona només perquè el punt final deixa de retornar errors.