Talk:Web application firewall

XSS protection bypass
I'm not good at editing wiki, but I want to help include that WAF's XSS protection is not sufficient. It's really easy to evade the XSS protection.[][] Julian88888888 (talk) 03:59, 10 September 2020 (UTC)


 * i have been trying to set time aside finish up a rework on the main section of this article. i think it could be nice to include that, but i dont think it should be mentioned in the description as that should be more general and easy for people to understand. additional sections going over that would be pretty awesome though. one thing to note is that we need to provide the information in the article itself. it shouldn't force the reader to have to leave the page to read what is mentioned. essentially just stating that it can be bypassed and not how its bypassed isn't very useful [imo]. I'm going to revert the change, but if you want, please suggest a change here so we can talk see where it would fit. also, please sign your comments with the 4 tildes so everyone knows who said what. Stay Free 76  talk 00:53, 10 September 2020 (UTC)


 * That's a good point about not forcing them to visit another page. I'm not sure how to condense the security research into a digestible format. How each WAF is bypassed via filter evasion is is nuanced. Maybe instead it could outline different kinds of WAF, and how each was bypassed via filter evasion? Maybe something like:
 * In 2015, eight WAFs were tested for XSS protection. All eight failed to protect against XSS attacks via filter evasion techniques. [first source?][]


 * For example, "Onwheel JS event +Resizingthe page by specifying the height on the style attribute" was able to trigger javascript on mousewheel events via ``


 * I welcome any help/revisions to try to update this because I do want to help. My biggest issue now is that in the intro description is that it says it protects against XSS, but I think it's not sufficient to say that, given how trivial it is to bypass that protection in the WAFs tested. Julian88888888 (talk) 03:59, 10 September 2020 (UTC)


 * that addition sounds awesome. maybe you can go even further like: ... xss protection from various vendors or even list a few of the more well known names too. i think it would still be pretty sweet if there was more "somewhat technical" stuff in the "other" sections. something like "Security bypass" for header, then mention a few of the xss issues listed in the document, how they work/ how they get around the system without putting the actual code. i think there could be a copyright concern here if the article is too close to the pdf source. that being said other articles have some sections that show example code in a block, so maybe you can add one example after the explanations. as long as the article does the explaining and it has sources then that's all we can ask for. ive been actively trying to fix a lot of the security appliance wikis past few weeks because some had tons of incorrect information. tbh, i haven't really gone through the article yet, so if you see something that should be there just remove it. as for the "protection" stuff, im with you on that. i think it could be reworded to say that the intent of the system is to detect/block those things, but they are 100% effective. also, if you use ":" before each paragraph it will intent 1 lvl per so the thread can be followed easier. (sometimes they get crazy and people respond to different people and it gets easy to lose track of whats going on.)  Stay Free 76  talk 04:50, 10 September 2020 (UTC)

WAF not recommeneded
A recent update of "They also introduce a performance degradation and are easily bypassed by attackers so their deployment is not recommended.[2]" seems to be inaccurate. As I understand it, WAFs are recommended and a standard part of cloud deployments and internet facing websites. The cited source appears to be an opinion piece with a fallacy that a WAF doesn't provide cost benefit because it doesn't solve all security within its remit (arguments presented could apply to normal firewalls or any security mitigation). — Preceding unsigned comment added by 125.168.93.24 (talk) 22:26, 24 January 2024 (UTC)