A blocked request is useful evidence only when you know which component blocked it. When testing path traversal and XML External Entity (XXE) requests, placement determines how easily you can connect a response to the WAF, the upstream application, or another proxy.

This guide compares two choices: placing SafeLine directly in front of a test application, and placing SafeLine behind an existing reverse proxy. The goal is a repeatable test that separates attack detection from routing and application behavior.

SafeLine documents its role as an HTTP/HTTPS reverse proxy that receives application traffic and forwards accepted traffic upstream. Its documentation also lists path traversal and XXE among the attack categories it addresses. Those statements establish the intended protection scope; they do not establish that every possible payload will be blocked. Sources: application configuration, product overview.

Choice A: Client to SafeLine to application

For an initial evaluation, use the shortest practical route:

Test client -> SafeLine -> staging application

The documented application setup asks for a domain, a listening port, and an upstream address. It then instructs you to resolve the application domain to the SafeLine server's IP address. HTTPS applications require selecting the SSL option. Source: application configuration.

This arrangement makes diagnosis easier because fewer components can alter the request or generate the response. First send an ordinary request and verify that the expected staging application responds. Then send one suspicious request at a time.

The official guide includes these query-parameter examples:

Path traversal: ?id=../../../../etc/passwd XXE: ?id=<?xml+version="1.0"?><!DOCTYPE+foo+SYSTEM+"">

These are examples from the documentation, not installation commands. The guide instructs readers to substitute their own protected domain, look for the blocking page, and inspect the attack list and its detail view in the web console. Source: documented attack tests.

Use an isolated application you control. For application-level traversal testing, prefer a harmless fixture file outside the intended content directory instead of attempting to retrieve operating-system files. Keep the documented query examples as smoke tests, and record the exact request your client actually transmits.

The main advantage of Choice A is clarity. Its limitation is that it does not reproduce transformations introduced by the production proxy chain.

Choice B: Client to existing proxy to SafeLine to application

A second evaluation can reproduce your existing delivery path:

Test client -> existing reverse proxy -> SafeLine -> staging application

This is a general test topology, not a claim that the supplied documents provide an integration recipe for a particular proxy. Confirm the routing behavior in your own environment.

Run the same request set used in Choice A. Keep the application version, upstream endpoint, and WAF configuration fixed so that placement is the principal variable.

An additional proxy may affect what reaches the next component. Check whether your actual configuration changes URL encoding, redirects requests, rejects bodies, or serves cached responses. These are possibilities to investigate, not assumptions about any specific product.

A rejection before SafeLine does not demonstrate SafeLine detection. Likewise, an application error does not demonstrate that SafeLine blocked the request. Correlate the client response with the SafeLine attack details and your upstream access records. If the evidence does not identify the rejecting component, mark the result inconclusive.

Choice B provides a more representative deployment test. Its cost is additional ambiguity when a request fails.

Build a comparison that answers useful questions

For each placement, capture the request method, path, query, content type, body, response status, response body, corresponding WAF evidence, and whether the upstream received the request.

Include three groups:

  • Normal controls: legitimate file references and valid XML accepted by the test application.
  • Documented smoke tests: the supplied traversal and XXE query examples.
  • Endpoint-specific tests: requests matching the application's real file-selection or XML-processing interface.

The distinction matters for XXE. An XML-looking query value can test recognition of suspicious input without exercising an XML parser. To evaluate the complete application path, use a staging endpoint that actually processes XML, with a harmless controlled fixture. Do not infer parser safety from a blocked query string.

For traversal, verify both sides of the boundary: legitimate file access should still work, while requests attempting to leave the intended directory should not expose the fixture. A WAF result and an application authorization result answer different questions.

Which placement should I test first?

Start with direct placement when you need a clear baseline. Then repeat the same cases through the production-like proxy chain to identify differences introduced by routing or request handling.

Does a blocking page prove the application is secure?

It demonstrates a blocked request on that tested route. It does not prove that the application is patched, that every encoding is covered, or that alternative routes cannot reach the upstream.

Is the documented XXE example a complete XXE assessment?

No. It is a useful smoke test. A complete assessment also examines the application's actual XML endpoint and parser configuration, using controlled fixtures and observable results.

What should count as a successful comparison?

Normal requests continue to work, suspicious cases have attributable outcomes, and the production-like route behaves as intended. Preserve inconclusive results explicitly. The strongest report explains which component handled each request and what the evidence establishes.

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.