This has been discussed to death every time security.txt comes up, but in my experience it's been a great way to receive spam about bullshit "vulnerabilities" from low effort scanners operated by "security researchers".
Much like how people publish email addresses online using human readable replacements (e.g. AT instead of @) to avoid spam, I'd rather put up a contact page that's easy for humans to find but nontrivial to automate.
Most of those are trivial to filter. Mentioning SPF or DKIM -> straight to the bin. Contains "critical" and "payment" -> straight to the bin. There's few patterns you'll find that will let you remove all the beg bounties.
> Contains "critical" and "payment" -> straight to the bin.
That sounds like an excellent way to accidentally filter out serious vulnerabilities. I'm glad you don't work for the vendor that received my urgent, critical (in all caps) unauthenticated remote code execution vulnerability report.
They were very grateful that I reached out and resolved it under 72h.
Did you write "I found critical vulnerability on your website, how much is your bounty, can you send PayPal payment?"
If it wasn't something close to that, then no, it wouldn't be filtered. If it wasn't obvious, the patterns are trivial, but not "check those two words" level of trivial. You need to apply common sense and adjust for your environment.
Yep I have received a genuine report completely unsolicited before, paid a modest bounty and fixed the problem immediately, then took some precautions to ensure any potential data leaks were rendered innocuous.
I was very glad to have received the info and I think folks such as yourself are doing valuable work.
Hint for applying ideas from comments: read information and understand the main point behind it, consider how it applies to your situation, then if it's beneficial try to implement it in a way relevant to you.
If you take comments like mine and try to implement them literally, that's stupid and it's on you.
Depending on your application, setting up SPF and DKIM can be complicated. And typically not having it set up is not a security issue, it may affect deliverability of your outgoing email, but is not a vulnerability.
(and indeed many beg bounties are about SPF or DKIM, because whatever automated tools they use to find the low hanging fruit didn't find anything more substantial).
Of course it's a security issue, because having neither SPF nor DKIM means that malicious actors can all too easily impersonate your email addresses and phish users with an email that apparently came from your domain.
I occasionally get what I'm sure are very well meaning SPF/DKIM-missing reports for a domain that has a null mx record.
It can basically be assumed that anyone trying to report that didn't do even a basic cursory look at the results. I don't need your automated scan, I have my own nessus deployment and already know what it's going to say.
"null record" is not "no record". It's an MX record of priority "0" and value "."
No MTA will try to deliver a message that is from or to a domain that has a null record. If you're the sender, your sending MTA might give you an NDR, but receiving infrastructure will just drop it.
Cloudflare actually has a wizard that implements it in addition to the items on the page you linked. And no offense to whoever wrote the CF article, but they are the new kids on the block relative to email.
> Null MX does nothing to prevent spoofing. It is just to signal to mail senders that your domain does not receive email.
And I also found multiple other sources that specify that the null record only announces that the domain does not receive email. After some googling I didn't find a single source that shares your explanation.
A large chunk of the beg bounty reports I see are "critical: your SPF is misconfigured, we'd like to share the details with you, how much are you paying".
Much like how people publish email addresses online using human readable replacements (e.g. AT instead of @) to avoid spam, I'd rather put up a contact page that's easy for humans to find but nontrivial to automate.