DEV Community

Lia
Lia

Posted on

How to Validate WAF Blocking with a Code Injection Test URL

#waf #security #testing #injection

A useful WAF validation connects three observations: normal traffic reaches your application, a documented attack test receives a blocking response, and the corresponding event appears in the WAF console. This gives you evidence about a specific request and traffic path.

SafeLine is a self-hosted web application firewall that filters and monitors HTTP traffic. Its documentation lists code injection among the attacks it protects against. The application setup guide also supplies a code injection test URL and explains how to check the blocking page and attack details. This walkthrough follows that documented approach. Sources: SafeLine introduction, application setup.

1. Prepare a controlled application and test record

Use an application you own or have permission to test, preferably in a staging environment. Choose a normal page that you can load before and after the test. Record the application hostname, test time, expected normal response, and the upstream address.

The documented test contains PHP function names. Treat it as attack-like input: do not create an endpoint that evaluates the query parameter, and do not assume the input is harmless if it reaches a vulnerable application. The purpose is to observe filtering, not to demonstrate successful execution on the server.

2. Check the installation prerequisites

The installation guide lists Linux, Docker version 20.10.14 or later, Docker Compose version 2.0.0 or later, and minimum resources of one CPU core, 1 GB memory, and 5 GB disk space. It also lists CPU instruction requirements and architecture considerations. ARM installations require a Pro license according to that guide, so check your intended deployment before proceeding. Source: installation guide.

Use the guide's prerequisite checks to inspect the host, then follow its installation procedure. Its recommended automated installation requires root privileges. Keep the official guide available during setup rather than adapting an incomplete installation snippet.

3. Open the console and configure the application

After installation, the documented console address is https://<safeline-ip>:9443/. The installation guide provides docker exec safeline-mgt resetadmin to obtain administrator credentials. Source: installation guide.

In the console, open Applications, select Add Application, and configure:

  • Domain: the hostname visitors will use.
  • Port: the port SafeLine will listen on.
  • SSL: select this option for an HTTPS application.
  • Upstream: the real address of the original application.

Resolve the configured hostname to the SafeLine server's IP address. These are the documented application setup steps. SafeLine acts as an HTTP/HTTPS reverse proxy, forwarding accepted traffic to the upstream application. Source: application setup.

4. Establish a normal-request baseline

Visit your normal application page through the configured hostname. Confirm that the page loads as expected before sending the attack test.

For this checklist, record the response status and a recognizable piece of page content. If normal access fails, resolve that problem first. An unavailable upstream, incorrect hostname, or TLS problem would make the later result difficult to interpret.

Also verify that your test hostname resolves to the SafeLine server. A request sent directly to the upstream does not validate the intended WAF traffic path.

5. Send the documented code injection test URL

The official guide gives this code injection query:

?id=phpinfo();system('id')

Append it to the HTTPS hostname of your controlled application. Replace the documentation's demonstration hostname with your own, as the guide instructs. Submit the request through the same hostname used for the normal baseline. Source: documented attack tests.

Record the submitted URL and test time. The guide identifies the appearance of SafeLine's blocking page as evidence that it defended against the test. A timeout or unrelated error page alone does not establish that result.

6. Correlate the response with the attack record

Open the SafeLine console's attack list and inspect the event associated with your request. The guide instructs users to select detail to view specific attack information. Compare the available details with your recorded test time and request. Source: application setup.

Finish by loading the normal page again. Your validation record should state whether normal access worked, whether the test displayed a blocking page, and whether a matching attack event was found. If those observations disagree, mark the result inconclusive and investigate the traffic path before claiming success.

FAQ

Does blocking this URL prove complete code injection protection?

No. It demonstrates the observed handling of one documented request under the configuration you tested. It does not establish coverage of every payload, application endpoint, encoding, or alternate route to the upstream.

Must the application execute PHP for this check?

You do not need to add PHP execution behavior. The documented procedure sends a URL containing PHP-like attack input and checks the WAF response. Adding executable behavior would introduce a separate application risk.

What if I see an error but no blocking page?

Treat the outcome as inconclusive. Check normal application access, hostname resolution, listener settings, and upstream configuration. Then inspect the attack list and repeat the controlled test after resolving any routing or availability problems.

What should I preserve as validation evidence?

Keep the test time, hostname, submitted query, normal-response observations, blocking-page capture, and corresponding attack details. Describe the conclusion narrowly: the documented test request was blocked on the tested application path.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)