CSP bloķē piekrišanas banneri

Kāpēc tas ir svarīgi

Stingrs CSP ir laba drošības prakse, bet, ja tas bloķē pašu CMP, vietne produkcijā var klusi zaudēt visu piekrišanas slāni.

Kā to pārbaudīt manuāli

1. Atveriet DevTools konsoli un meklējiet CSP pārkāpumus, kas saistīti ar CMP resursiem.
2. Pārbaudiet, vai tiek bloķēti bannera script, CSS, iframe vai API endpoint.
3. Salīdziniet CSP uzvedību lokāli un produkcijā, ja problēma redzama tikai produkcijā.

Tipiski cēloņi

• CMP domēni nav atļauti script-src, frame-src vai connect-src noteikumos.
• Nonce vai hash balstīti CSP noteikumi nesedz CMP inline bootstrap kodu.
• Deploy laikā CSP headeri mainīti bez CMP atkarību atkārtotas validācijas.

Labojums GTM

1. Nepaļaujieties uz GTM kā workaround, ja CSP bloķē pašus CMP assetus.
2. Pārskatiet, vai GTM ievietotie CMP fallback nesaskarās ar tiem pašiem CSP noteikumiem.
3. Pēc CSP headeru atjaunināšanas produkcijā pārtestējiet vietni.

Labojums WordPress vai CMP spraudņos

1. Pārskatiet security spraudņus, hostinga headerus un CDN noteikumus, kas ievieto CSP.
2. Allowlist tikai tos CMP domēnus, kurus bannera konfigurācija tiešām izmanto.
3. Pēc header izmaiņām pārtestējiet ar izslēgtu browser cache.

Vispārīgs izstrādātāja labojums

1. Allowlist tikai minimāli nepieciešamos CMP origin scriptiem, frame un API pieprasījumiem.
2. Dodiet priekšroku mērķētām CSP izmaiņām, nevis visas politikas vājināšanai.
3. Versiojiet CSP noteikumus un atkārtoti testējiet banneri pēc katras izmaiņas.

Kā apstiprināt, ka labojums darbojas

• Apstipriniet, ka CSP kļūdas, kas saistītas ar CMP assetiem, pazūd.
• Apstipriniet, ka banners normāli renderējas un pieņem lietotāja mijiedarbības.
• Palaidiet jaunu scan un pārbaudiet, ka bannera issue pazūd.