Open Querybuilder Endpoint on Publisher | Community
Skip to main content
G
Gunars_V
Level 3
May 8, 2025
Solved

Open Querybuilder Endpoint on Publisher

  • May 8, 2025
  • 2 replies
  • 768 views

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" }
Best answer by SantoshSai

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!

2 replies

SantoshSai
Community Advisor
SantoshSaiCommunity AdvisorAccepted solution
Community Advisor
May 9, 2025

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!

Santosh Sai
    G
    Gunars_VAuthor
    Level 3
    May 9, 2025

    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/dispatcher-configuration#configuring-access-to-content-filter

    G
    Gunars_VAuthor
    Level 3
    May 12, 2025

    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.


    @santoshsai <Location> worked perfectly, thanks again!

     

    AmitVishwakarma
    Community Advisor
    AmitVishwakarmaCommunity Advisor
    Community Advisor
    May 9, 2025

    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



    G
    Gunars_VAuthor
    Level 3
    May 9, 2025

    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/dispatcher-configuration#configuring-access-to-content-filter

    Terms & ConditionsAccessibility statement

    Loading footer...