Open Querybuilder Endpoint on Publisher

[Gunars_V]

Hi, I have a requirement to open the QB endpoint so that a third-party service can use the JSON output. Besides adding a filter specific to the query, is there anything else that would be recommended to add to Dispatcher config?

Currently, I have something like this:

/0100 { /type "allow" /method "GET" /url "/bin/querybuilder.json" /extension "json" /query "regex specific to query here" }

[SantoshSai · Accepted solution]

Hi @Gunars_V,

Exposing the QueryBuilder endpoint (/bin/querybuilder.json) on the publisher is generally not recommended unless you're very careful - this endpoint can be used to craft expensive or malicious queries that may impact performance or expose sensitive content.

If you must expose it for a third-party service, here’s how to harden the configuration as much as possible:

1. Restrict by query pattern (as you're doing)

Continue using the /query filter with a strict regex that matches only the expected and safe query structure:

/url "/bin/querybuilder.json"
/method "GET"
/extension "json"
/query "your-safe-regex"

Make sure this regex:

• Only allows known paths

• Prevents deep traversals like path=/content without limit

• Does not allow dynamic filters (like orderby, nodename, etc.)

2. Restrict by IP or client certificate

If the third-party system has a static IP, restrict access to only that IP:

/allow {
  /type "allow"
/url "/bin/querybuilder.json"
/method "GET"
/extension "json"
/query "your-safe-regex"
/ip "198.51.100.25"
}

Or configure client certificate-based access (mutual TLS) if applicable.

3. Rate limiting (Optional but recommended)

Apply rate limits via your load balancer or WAF (e.g., Cloudflare, Akamai, etc.) to prevent abuse.

4. Use a custom servlet or wrapper instead

Instead of exposing /bin/querybuilder.json, you can create a custom servlet that:

• Internally uses QueryBuilder

• Validates and sanitizes all inputs

• Returns only the specific data needed

Then expose only this custom endpoint in Dispatcher. This gives you full control.

Hope that helps!

[Lokesh_Vajrala]

I agree with Santhosh and recommend writing a servlet to validate the request parameters and run queries. 

[Gunars_V]

Hi @SantoshSai, I appreciate your insight. Is IP filtering available under /filter section? I wasn't able to find information about that at the dispatcher documentation: https://experienceleague.adobe.com/en/docs/experience-manager-dispatcher/using/configuring/dispatche...

[SantoshSai]

Hi @Gunars_V,

Yes, you're right to double-check - IP filtering is not configured directly under the /filter section in the dispatcher configuration.

Instead, IP-based access control is typically managed through Apache HTTP Server directives, not Dispatcher’s /filter section. You can apply IP restrictions using mod_access or mod_authz_core in your Apache configuration like this:

<Location "/bin/querybuilder.json">
    Require ip 192.168.0.0/16
    Require ip 203.0.113.42
</Location>

This ensures only specific IPs can access sensitive endpoints like /bin/querybuilder.json.
The /filter section in dispatcher.any is mainly used to allow or deny resource paths, not network-level restrictions.

[Gunars_V]

@SantoshSai <Location> worked perfectly, thanks again!

[AmitVishwakarma]

Hi @Gunars_V ,

In a previous project, we had a requirement where a trusted external service needed to consume structured content from AEM in JSON format. The initial idea was to expose /bin/querybuilder.json, but we quickly flagged the risks — unrestricted access, no input validation, and potential for performance hits.

Solution:
1. Custom Sling Servlet (Wrapper around QueryBuilder)

A safer way is to build a custom servlet that:

  - Accepts only whitelisted query parameters (e.g., q, path)

  - Hardcodes safe values for predicates like type, path, p.limit

  - Filters out risky options like orderby, nodename, or deep traversals

  - Controls and sanitizes the response (you can choose what fields to include)

Example predicate setup inside the servlet:

predicateMap.put("path", "/content/site-a");
predicateMap.put("type", "cq:Page");
predicateMap.put("p.limit", "10");
predicateMap.put("fulltext", searchTerm);

Dispatcher Configuration

Expose only this custom endpoint — not the default /bin/querybuilder.json.

/0100 {
  /type "allow"
  /method "GET"
  /url "/bin/secure/search"
  /extension "json"
  /ip "203.0.113.10"   # IP of the trusted third-party system
}

If IP restriction isn’t possible, consider mTLS or token-based access.

Extra Safety Steps That Helped:

Rate limiting at CDN or load balancer to avoid abuse

Input sanitization for all parameters — don’t trust anything from the request

Audit logging of each request (query string, IP, timestamp)

Error handling with meaningful HTTP status codes

Regards,
Amit

[Gunars_V]

Hi @AmitVishwakarma, thanks for this. Is IP filtering available? I wasn't able to find documentation around that at the following link: https://experienceleague.adobe.com/en/docs/experience-manager-dispatcher/using/configuring/dispatche...