NAXSI is usually referred to as a « Positive model application Firewall ». It is an open-source WAF (Web Application Firewall), providing high performances, and low rules maintenance Web Application Firewall module for the most famous reverse proxy NGINX.
NAXSI is an acronym that stands for Nginx Anti Xss & Sql Injection. Its ultimate goal is to prevent any attacker from leveraging web vulnerabilities on any site, no matter what language is used to develop it. We also like to refer to NAXSI as a tool to protect websites from the  TOP 10 OWASP threats.

Why a web application firewall?

Web applications nearly always have a kind of customization. Even when it’s a basic CMS, fine-tuning and custom modules often come into play; so to sum it up :

Customized web application:                                                                         Classic web application:

As long as it is customized and « tuned », you can’t address security issues in a genericautomated way, as you can do for most technical services, which rely on patches and security updates. You indeed need to take care of your own security issues.

NAXSI, yet another web application firewall?

NAXSI is an Nginx module in charge of performing web application firewalling. However, while most web application firewalls rely on rather complex signatures (often in the form of regular expressions), it might become very hard to read & maintain. Example from mod_security :

"(?:\b(?:(?:type\b\W*?\b(?:text\b\W*?\b(?:j(?:ava)?|ecma|vb)|application\b\W*?\bx-(?:java|vb)) \

script|c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder|iframe\b.{0,100}?\bsrc)\b| \

on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)| \

s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b \

(?:(?:java|vb)script|shell|http)|ivescript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)| \

background-image|mocha):|s(?:(?:tyle\b\W*=.*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb) \

script|shell|http):)|a(?:ctivexobject\b|lert\b\W*?\(|sfunction:))| \

<(?:(?:body\b.*?\b(?:backgroun|onloa)d|input\b.*?\btype\b\W*?\bimage)\b| ?(?:(?:script|meta)\b|iframe)| \


NAXSI instead will rely on simple rules, mostly focusing on “dangerous” characters and expressions, such as < > ‘ () [] {} ; ….. Once any of those characters or expressions are a match within an incoming HTTP request, NAXSI will increase the “score” of the request (sqli, XSS, TRAVERSAL, …). And, if and only if the request reaches one of the limits configured by the user, it will take an action on the incoming request, such as blocking it.
Thus, instead of limiting the access to known atacks signatures and to authorize all other requests (blacklisting), NAXSI blocks, by default, all traces and suspicion of ny attack by basing itself on the aforementioned characters, which are often part of the code injected by attackes in web requests (whitelisting).

Strengths and weaknesses of the NAXSI approach


  • Good resilience against unknown/obfuscated attacks
  • Good performances (low mem footprint, minimal runtime processing)
  • No need for updates of “attack” signatures
  • Strongly assisted learning process
  • Administration requires less knowledge than most WAFs


  • Initial learning is needed
  • Fast evolving apps requires coordination with releases
  • No “intelligence”, unsuitable for some specific cases

As you might see, the strongest downside of the NAXSI approach is the need for configuration. This “naive” approach used is very efficient, but very prone to false positives as well. However, don’t worry, NAXSI comes in with handy tool “nxtool” to assist you:

CaptureNXTOOL has several purposes

  1. Injection of all NAXSI events within an ElasticSearch database: this is both helpful to the learning process and for the visualisation of incoming events.
  2. Whitelist generation: Nxtool will attempt to generate suitable whitelists for your application, so that you don’t have to do it manually.
  3. Reporting: the Nxtool command line allows you to quickly get a view of where most exceptions are happening, and give you a direction of what to focus learning process on.

Here, when we are discussing about « learning », we refer to the fact of identifying « false positives » and allowing them. If we do not perform this phase, we take the risk of locking out legitimate users from the application. On the other hand, if we allow « too much », we might leave a window of exploitation for an external attacker. This is indeed a crucial task.


Thanks to ElasticSearch and Kibana, it’s rather trivial to get a real time view of what is happening. This is extremely useful for administrators / security teams, as it shows if an attack is happening, or if a new website appeared for which learning must be done.


Whitelist generation and learning

There are 3 possibles approaches to learning:

  • Exhaustive, custom learning : will provide the most accurate filtering
  • Relying on templates : Depending on your application, you can rely on one of the existing templates for your application
  • Black-list only : Relying on third parties ruleset, you can decide to opt for the blacklist approach. This allows you to mostly skip the learning phase. However, it does not provide the best protection, because it will be only to block what it’s « aware » of

Exhaustive learning

While covering every detail of exhaustive learning might require a post on its own, here is walkthrough of NXTOOL’s behaviour. Nxtool will suggest whitelists based on the data present into ElasticSearch. It will provide those whitelists based on several possible factors:

  • Statistics : if – let’s say – more than 20 % of your peers are triggering the same event, it is probably a false positive
  • Known behaviour : some specific applications have predictable behaviour, and nxtool will identify those. It will suggest that they be associated whitelists (for instance Google analytics in cookies…)

Exhaustive learning is done via NXTOOL in command line (see github wiki’s page for more details):
$ python -c nxapi.json -s -f

#Rule (1310,1311) : ] [ in stuff

#total hits 58

#'peers': u'x.x.x.x'

#'peers': u'y.y.y.y'


#'uri': u'/js/index.php'

#'var_name': u'name[]'

#'var_name': u'street[]'


# success : rule_ip is 345

# success : global_rule_ip_ratio is 17.0


BasicRule wl:1310,1311 "mz:$URL:/js/index.php|BODY|NAME";

Blacklist approach

Blacklist approach is the exact opposite: Instead of allowing explicitely the anomalies we choose, we will specifically disallow requests matching known attack patterns.

Doxi-rules (NAXSI’s blacklists) are edited and maintained by a third party (marre-system), and can be found here:

It comes along with a CLI tool that allows to easily update signatures and create reporting.

To conclude

shema naxsi_2NAXSI is thus an open-source WAF, based on a whitelist approach, allowing to filter users’ requests at the level of the reverse proxy NGINX to protect websites and applications from potential attacks.

Very easy to set up, this tool becomes very performant when the learning phase has been correctly dealt with. It is then able to protect your application against the OWASP top 10 threats and notably attacks such as SQL Injections, XSS, Traversal…

This tool is one of the 20 security layers included in the CerberHost: high security hosting offer by NBS System.

Thibault Koechlin
Thibault is NBS System’s RSSI and manages the company’s Security team. This specialist in security services, an activity he keeps doing for our clients, is also the creator of NAXSI, an open source Web Application Firewall, and CerberHost, a unique secure Cloud solution.