Wildness with wildcards, or why DuckDuckGo wouldn’t go

A quick tip about Content Security Policy prissiness where URLs’ wildcards are concerned.

2022-07-15

Just passing this along FYI . . .

Using information from David Papendrew’s article, “Using DuckDuckGo for Site Search on Your Blog,” I recently added a DuckDuckGo search form to the bottom of each page of the site. It worked perfectly well in local development, but not when I actually published the site to the web.

It didn’t take long to figure that this had something to do with the form-action directive of my site’s Content Security Policy (CSP), so I added DDG’s domain to the directive:

form-action: 'self' https://*.duckduckgo.com;

. . . and figured that would do the job.

However, no such luck. The browser still reported via its console that it wouldn’t send form data to https://duckduckduck.go because that was a violation of the CSP’s form-action directive.

I then wondered whether this was happening because of the * wildcard character that I’d used in specifying that URL in form-action. As an experiment, I changed the form-action directive to:

form-action: 'self' https://*.duckduckduck.go https://duckduckgo.com;

. . . and then it worked. </ForeheadSlap>

So if you’re having similar difficulties getting such a form to work on a site with a strict CSP, here’s hoping this info gives you some relief.

By the way, it turns out I’d have gotten my answer earlier if I’d only checked around a little more (</ForeheadSlap> again):

Update, 2022-07-16: I realized after publishing this that someone could very easily wonder why I didn’t simply set the CSP to Report-Only, so everything would work but I’d get some data indicating why the form wasn’t going through. Well, I did try that first — but, for reasons unknown to me, the reporting didn’t even flag the error. This left me with only the alternative of taking the CSP live. Of course, that’s definitely not an advisable practice for debugging the CSP on a site with a lot of traffic.

Next:

Previous: