A number of source-code hosting services (Gitlab, Github, Bitbucket, Gogs, and others) have the ability to send webhooks when new commits are pushed to a repository. The webhooks are usually HTTP POST requests with a JSON payload.

Out of the box, Jenkins 2.x enables a security feature called "Prevent Cross Site Request Forgery exploits" that rejects all POST requests that don't have a valid 'crumb' token associated with them. This is a great security feature.

Since most Git hosting services don't have any mechanism to retrieve or handle a crumb, that means that their POST requests get blocked on a Jenkins installation with default settings. "Prevent Cross Site Request Forgery exploits" needs to be manually disabled in order to allow the host's webhooks to work with Jenkins out-of-the-box, or a service-specific plugin needs to be installed.

There are plugins written for a lot of big-name hosts (e.g. Bitbucket and Github) that provide CrumbExclusions for those specific hosts. This method works (and lets us keep CSRF enabled), but it means that every hosting service needs its own special Jenkins plugin just to trigger a remote SCM poll. It also means that a lot of smaller or self-hosted services get left in the dust.

Would it be possible to add a configurable domain-name whitelist to the CSRF protection feature? That would let a Jenkins installation receive POST requests from specific servers and still keep general CSRF protection in-place. This could maybe take the form of a text-box on the "Configure Global Security" page where we could add whitelisted domains.

This is a general-purpose fix that would permanently solve all issues of this general type:
https://issues.jenkins-ci.org/browse/JENKINS-33878
https://issues.jenkins-ci.org/browse/JENKINS-30384
https://issues.jenkins-ci.org/browse/JENKINS-25421
https://issues.jenkins-ci.org/browse/JENKINS-22474
https://issues.jenkins-ci.org/browse/JENKINS-20140
https://issues.jenkins-ci.org/browse/JENKINS-10263
https://issues.jenkins-ci.org/browse/JENKINS-14372