Page History

Note: This vulnerabilility has been fixed.

...

• Incorrect referer check: "There are also common implementation mistakes with referer checks." I think that we have satisfactorally avoided the mistakes. (But hard to convince someone of that - or prove it.)
• No referer header set: Request may not have a referer header set. We simply do not allow them access, which is acceptable for our use-case.
• Browser support: Previously, not all browsers protected the referer header properly. Now they do. Its possible that someone has installed a browser extension/plugin that does something strange, but I dont think we need to cover that case. (We could add this to our browser support page)
• Doesnt always work: There are many quotes like this "Referer checking can detect some attacks but not stop all attacks", but after much searching I find no reference to anything besides the above items - in other words things that are not a problem for us. I have seen no indication that a referer can be spoofed in a CSRF context.

...

Also security scanning software is apparently looking for CSRF tokens on forms.

Ive seen these two mentioned.

• Acunetix (https://devnet.kentico.com/questions/regarding-csrf)
• HP fortify

Conclusion

Based on the above, I think it is most important that Magnolia is percieved well and adheres to the established best practices. While our referal protection is good, it is not generally accepted and therefore will be mistrusted in many secuirty audits. In brief - many customers and potential customers will trust the OWASP page more that they will trust our reassurances that our system is secure.