Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Navegador Javascript Spam Privacitat

La caché o minificació trenca el nonce d’un formulari WordPress

Corregeix nonces caducats per caché, CDN, variants, retard d'scripts, formularis duplicats i excepcions de sessió.

Un nonce ajuda a confirmar que una petició procedeix d’una pàgina i finestra temporal esperades; no és permanent. Servir HTML antic o barrejar versions d’assets pot fer que un visitant enviï un token que el servidor ja no accepta.

Demostra la discrepància abans d’excloure tot el web de la memòria cau.

Captura la resposta fallida

Envia dades sintètiques sense sessió i inspecciona el codi i la resposta amb dades ocultes. Anota si WordPress indica nonce invàlid o caducat, error de seguretat o 403 genèric.

Relaciona l’hora amb PHP i seguretat. Un 403 de Cloudflare o ModSecurity pot semblar igual i pertànyer a una altra capa.

No comparteixis el nonce; tracta’l com una dada de seguretat temporal.

Compara visitants amb caché i sense

Prova una finestra privada, una vista bypass disponible per a administradors i l’URL pública normal. Examina les capçaleres d’estat i edat.

Si falla la pàgina pública i funciona la còpia no cachejada amb el mateix formulari, l’edat o la variació són evidència sòlida. Un sol test amb login no serveix perquè normalment s’exclou.

Registra variants mòbil, escriptori, geogràfica o CDN. Compara també les galetes i capçaleres que formen la clau de caché. Una variant anònima es pot servir erròniament a usuaris amb consentiment o sessió diferent si el CDN ignora una cookie necessària.

Revisa la vida de la pàgina

Compara la validesa esperada del nonce amb el TTL de la pàgina i el CDN. La pàgina no ha de servir un token després que WordPress deixi d’acceptar-lo.

Utilitza la compatibilitat documentada pel plugin o la caché. Alguns formularis refresquen mitjançant AJAX; confirma que aquesta petició no es cacheja ni es bloqueja.

Verifica que el token renovat s’escriu a la mateixa instància que s’enviarà i que la resposta no procedeix d’una altra memòria cau. Registra les hores de generació i enviament sense copiar el nonce.

Exclou només pàgines o fragments amb estat dinàmic. Verifica també el rellotge del servidor.

Evita cachejar endpoints

Les respostes POST, AJAX i REST no s’han d’emmagatzemar com a èxits o errors reutilitzables. Revisa les regles CDN i del servidor per a l’endpoint exacte.

Una resposta d’èxit cachejada pot afirmar que s’ha enviat un lead quan WordPress no l’ha processat. Purga l’endpoint després de corregir la regla.

Revisa també els mètodes i codis: una regla CDN no ha de compartir la clau de POST amb GET ni emmagatzemar respostes 403 o 422 per a altres visitants.

No desactivis tota la seguretat REST com a solució.

Revisa l’optimització JavaScript

Minificar canvia el format, però combinar, retardar i reordenar dependències pot impedir refrescar el token o iniciar amb dades antigues.

Inspecciona la consola i les versions. Exclou del delay/combine el handle mínim demostrat i regenera els assets.

No incrustis un nonce en un fitxer JavaScript estàtic; genera’l o obtén-lo mitjançant el mecanisme compatible.

Busca diverses còpies del formulari

Un maquetador pot generar formularis mòbil i escriptori amb ID duplicats i tokens diferents. L’script potser actualitza només el primer mentre s’envia el segon.

Inspecciona el DOM i les peticions. Prefereix una instància responsive o assigna identificadors únics.

Neteja CSS/JS del maquetador només després de corregir la duplicació.

Mantén intacta la seguretat

No desactivis la validació, allarguis tokens indefinidament ni acceptis qualsevol petició anònima. La reparació ha de servir estat fresc i conservar la comprovació legítima.

Combina el nonce correcte amb validació al servidor, antispam i rate limits.

Ofereix una alternativa supervisada si el formulari crític continua inestable.

Verifica tots els estats de caché

Després de reparar, purga la pàgina o l’objecte CDN afectat i envia des d’una sessió pública nova. Repeteix quan la caché s’hagi escalfat i prop del TTL quan sigui viable.

Confirma una petició, una entrada, una notificació i l’arribada. Prova variants mòbils i estats de consentiment.

Demana reparació urgent si diverses capes discrepen o l’endpoint retorna èxits cachejats. Comparteix URL, capçaleres i estats amb dades ocultes, mai nonces, galetes o contingut.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència