Content-Security-Policy uses 'unsafe-inline' for scripts

MediumLikelyOpenPaymentsfix by 30 Nov

Open · Payments's

Nobody has it yet

It's Payments's, but no one has picked it up.

Where it came from, and where it is

One problem in one place, found by scan.

1 source · 1 place

Scan
Standard scan of tessellatepay.com, Mon 12 Oct
First found Thu 1 Oct, last seen Mon 12 Oct
- app.tessellatepay.comOpen

What closes it

Not yet: A complete scan stops seeing it on app.tessellatepay.comThe rescan of tessellatepay.com running now can settle it

Nobody can mark it fixed by hand. A person submits the fix; a scan or a retest decides it.

Why it ranks here

30th of 39 in your queue

Proof first, then exploitation in the wild, a public exploit, EPSS and severity, adjusted for exposure and how much the asset matters

Priority

36 / 100

Medium Where its severity starts it26
Behind your edge Cloudflare or CloudFront answers first+2
Criticality A Money moves or customer data lives here+8
Its priority36

The evidence

What each source saw

As each source gives it · secrets, keys and card numbers stay masked

The scan's case file · tessellatepay.com

See it in that scan

What we saw

Sent, but it uses 'unsafe-inline' for scripts:default-src 'self'; script-src 'self' 'unsafe-inline' https://www.googletagmanager.com; object-src 'none'

The fix

Add the header at your edge (Cloudflare can set it for every host at once) or in the app.

Where

Activity

What happened, and what was said

1 event · 0 comments · oldest first

SecureAssure found it in the deep scan of tessellatepay.comThu 1 Oct, 01:00

⌘ Enter to send