At the Django level, we already try to tune out the very common DisallowedHost exception that Django throws when it encounters spoofed hostnames that are not in ALLOWED_HOSTS. However, there's a certain class of vulnerability scan/attempt which fakes a hosthame that doesn't comply with the RFC, so seems to trigger DisallowedHost but in a way that isn't filtered out. Originally it was thought that this was a different code path in Django, but it's not, so maybe the Django-oriented logger filtering isn't working as expected any more.
This means that Sentry gets a reasonably high volume of errors that we could just be ignoring, and which will be eating into quotas, so it makes sense to find a way to tune these out, too
Context
At the Django level, we already try to tune out the very common
DisallowedHostexception that Django throws when it encounters spoofed hostnames that are not inALLOWED_HOSTS. However, there's a certain class of vulnerability scan/attempt which fakes a hosthame that doesn't comply with the RFC, so seems to triggerDisallowedHostbut in a way that isn't filtered out. Originally it was thought that this was a different code path in Django, but it's not, so maybe the Django-oriented logger filtering isn't working as expected any more.This means that Sentry gets a reasonably high volume of errors that we could just be ignoring, and which will be eating into quotas, so it makes sense to find a way to tune these out, too
Success criteria
DisallowedHostevents are sent to Sentrybedrockhttps://github.com/mozilla/bedrock/pull/11381nucleushttps://github.com/mozilla/nucleus/pull/625baskethttps://github.com/mozmeao/basket/pull/820