I am allowing following character in regex that is dash, tilde, attherate, a-z, A-z, 0-9

[A-za-z_0-9.,\t\r()\\[\\]@ ~/[-]+$]
  1. Is there any possibility to bypass these regex?

  2. Actually, whenever request came to server, request hits to this page first. Is it safe?

  3. actually application is huge in nature so I can't apply encoding on each and every response instance. Is there any way to mitigate commonly?

  • 1
    I can't apply encoding on each and every response - Why not? If you can check the regex on every input, you can encode on every output. – MechMK1 Aug 9 at 10:11
  • Using regex could really slow down your application and result in a denial of service attack when a lot of simultaneous requests are made. There is NO reason why you could not perform output encoding. Stating the application is too big is not a valid reason to not do this. – Jeroen Aug 9 at 10:29
  • @MechMK1 i am not applying validation on every input i am apply for every request.like request hit to server than these logic fires and check whether input contains any invalid character. – useradmin1234 Aug 9 at 11:02
  • Then several characters, such as % or = are missing. In my opinion, you are going the completely wrong way. The reason why everybody recommends output encoding isn't because of cargo cult, but because it has a successful history of solving the problem. – MechMK1 Aug 9 at 11:56
  • 2
    @ConorMancone There are no shortcuts to security, sadly. OP has to invest some ressources into this. – MechMK1 Aug 9 at 12:18
  1. Is there any possibility to bypass these regex?

I am not very confident in the regex, because if I do a string like "abc" or "alert(1)" it says no match on both. XSS can be obfuscated as well, meaning a good regex to catch XSS is not an easy task to write, for more information have a look at https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

  1. actually application is huge in nature so I can't apply encoding on each and every response instance. Is there any way to mitigate commonly?

You should architect application with security in mind before you develop it. I would suggest re-factoring your code so that all output, no matter of location is encoded with html entities.

Example for C# https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.htmlencode?view=netframework-4.8


I agree with the answer from @RaimondsLiepiņš. To expand a bit more though, it's important to understand that the nature of how you prevent XSS depends on the context, which is why proper encoding of output is the most effective solution. Trying to preemptively clean all input can work, but also tends to be a clunky solution that causes other issues for users, and even still isn't always successful. Context-aware output encoding is the only sure-fire solution.


To give an example of where your current regex will fail, it will fail if user input is injected into javascript that's not enclosed in quotes. Imagine a URL like this:


The id parameter gets injected into some javascript on the page like this:

var resourceId = [ID_FROM_URL];

In this case, your regexp does nothing to stop active exploitation with a payload like:


If you don't have any cases like this, then your regexp might protect you. It's impossible to say for sure though, because with XSS it all depends on context. This is why trying to apply one rule to all input tends to leave security holes - there are too many possible issues.

Problems for users

Even if your regexp did fix all your XSS, it is still causing a lot of trouble. The issue is that you are preventing virtually all non-ascii characters from being used in user input. That will be unfortunate for anyone who uses your system and is Irish (i.e. Conor O'Brian), anyone from every continent except North America (aka my good pal Jávier), anyone who speaks 普通话/普通話, and anyone who needs to quote what "the other guy said".


The only real solution, therefore, is to just do it right. I'm going to guess that you work for a company that built a large software system and only afterward learned about basic application security. Unfortunately this happens more commonly than you would hope. In the long run you're really only going to have one option: re-do it. Trying to bolt security onto a system that wasn't built securely is a losing proposition. Eventually you'll either end up rebuilding your system with a more solid foundation, or you'll end up very, very hacked. Those are the only long-term options.

In the short term you could also try implementing a strict CSP to mitigate the potential damage from an XSS attack, although typically implementing a tough CSP is very difficult for systems that weren't built securely in the first place.

  • 1
    The best advice is simply to bite into the sour apple and do things right. Because I guarantee you that some blackhat definitely will find a vuln in there - and that damage will be way worse. – MechMK1 Aug 9 at 12:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.