The block page a user sees is the visible face of your security decision.
When a user is blocked, the generic "access denied" message they see is not merely a technical output — it is part of the organisation's security experience. An enterprise customer, citizen, partner or end user wants to understand why they are being held, what they should do next, and whether the situation is temporary or permanent. Blunt, unbranded error pages turn a security decision into an unprofessional experience.
During a DDoS or bot attack, showing users only an error is rarely enough. Real users need to be told that their request is being verified, that automated traffic is being separated, and that the session will continue shortly. A countdown, a challenge and a CAPTCHA flow serve both a security and a communication purpose at this moment.
In multi-language, multi-tenant environments the same page does not suit everyone. A bank may want to show an explanation in the local language with corporate colours; a service provider may need a different logo and message for each tenant; an API endpoint needs a JSON error body rather than an HTML page. A single fixed block page cannot satisfy these requirements.
Reason codes matter for help-desk and security teams as well. When a user reports an error, the support team needs to understand which rule, which bot decision or which WAAP action was triggered. That information must be delivered with control — visible to the user in some cases, kept in logs and support flows only in others.
TR7's approach takes block pages beyond static error output returned after a security decision, turning them into a customisable WAAP experience shaped by brand, language, reason code, CAPTCHA, DDoS challenge and API response format.
Our approach
TR7 manages block pages through ready-made templates, EJS rendering, native response serving and reason code injection.
Ready-made page categories cover different security actions
Separate template structures are available for DDoS challenges, JavaScript verification, CAPTCHA, bot protection errors and AAM 503 responses. Each page type can be designed to match a different user experience and security decision.
EJS templates manage theme, colour and language
CAPTCHA pages are built with EJS templates. Theme, size, background colour, text colour and the language dictionary can all be applied at render time.
Pages are served directly from the proxy layer
TR7 can return a block or challenge response without reaching the backend. This approach reduces latency and prevents unnecessary load on the application layer during an attack.
Reason codes and request variables can be injected into the page
Reason codes and custom request variables can be placed inside templates in a controlled manner. This helps support teams identify the cause of an error and, where appropriate, gives the user a meaningful explanation.
Capabilities
TR7 Block Page Customization centrally manages HTML, CAPTCHA, challenge and JSON responses for different WAAP decisions.
DDoS challenge page keeps real users calm while requests are verified
TR7 can use custom challenge pages for DDoS scenarios. These pages can include countdown timers, user messaging and verification status. Real users are informed that their request is being processed and will continue shortly. This means that during an attack, the outcome is a manageable user experience rather than just a block.
JavaScript verification page helps separate automated traffic
DDoS JS solver pages support a browser-based verification flow. Client-side control logic targets the separation of automated traffic from legitimate requests. Ready-made files are available in English and Turkish. Additional languages or custom text can be covered through the template structure.
CAPTCHA EJS template manages theme, size and language flexibly
CAPTCHA templates drive the full CAPTCHA experience. The `auto`, `dark` and `light` theme options and `small`, `medium` and `large` size options are all available. Background and text colours are controlled through parameters. This structure aligns the security verification step with the organisation's visual identity.
Text and invisible CAPTCHA types adapt to different flows
Text or invisible modes can be selected in the CAPTCHA configuration. Text CAPTCHA suits situations where users are required to respond explicitly. Invisible mode is preferred in scenarios where lower friction is the goal. The same security control can therefore be adjusted to different user experience targets.
Language dictionary supports adding new languages at template level
TR7 ships with ready-made English and Turkish CAPTCHA text dictionaries. Around 16 text fields — including title, description, input placeholder, submit, refresh, verifying, verified, failed, error and expired — are managed per language. New languages can be added by extending the translation object inside the template. The multi-language structure is provided this way; users add the languages they need.
Per-vService CAPTCHA configuration provides tenant and application separation
Each vService can use a different CAPTCHA configuration with its own appearance and behaviour. This matters in multi-tenant, MSSP or multi-brand deployments. Every application on the same TR7 instance can run with its own colour, language, text and verification style. Security controls remain centralised while the user experience is separated per tenant.
Bot protection error page handles bad automated traffic separately
A dedicated error page can be used for bot protection decisions. When a bad user agent, automated behaviour or bot protection rule is triggered, a separate response can be returned to the user. This page can be customised to match the brand's tone and the support workflow. The technical reason code can be kept internal or surfaced in a controlled way as needed.
AAM 503 page delivers a controlled message when the backend is unreachable
When the backend is unreachable or a pool is temporarily unavailable, a custom AAM 503 page can be used. This page prevents users from seeing an empty browser error or a meaningless connection drop. Planned maintenance, temporary load spikes or service access issues can be presented with a clear, understandable message. The organisation retains brand control and support guidance even during an outage.
Custom WAAP actions can return HTML or JSON responses
TR7 can return a custom response with a specific status code, content type and file content as part of a WAAP action. An HTML page, plain text or a JSON error body for API endpoints can all be used. File-based or inline content delivery models are both supported. This flexibility allows different blocking experiences for web users and API clients.
Reason code injection speeds up support and incident triage
Request variables or transaction-level reason codes can be embedded in page content. The help desk can use a screenshot or error code from the user to identify which security decision was triggered more quickly. The security team decides which information is shown to the user and which stays in logs only, as a matter of policy. This structure increases debug speed while keeping information leakage under control.
Operational depth
Reliable block page delivery requires coordinated planning across file serving, language addition, status code selection, dynamic variables and static asset management.
Language extension model
Adding a new language to the CAPTCHA template is done by defining a new language dictionary in the relevant translation object. Title, error, verification and wait texts are separated per language. This approach ties multi-language support to an extensible template structure rather than a fixed product list.
Asset file paths
Base path, JavaScript serve path, HTML file and JavaScript file for CAPTCHA and challenge pages are each managed through separate configuration fields. This separation ensures static content is served from the correct path. File layout stays readable across multiple page types.
Native response serving
When a condition is met, TR7 can produce an HTML or JSON response directly using its native response mechanism. That response is generated without contacting the backend. For challenge, CAPTCHA and custom WAAP actions, this eliminates both latency and application load.
Status code flexibility
Different HTTP status codes can be used for different scenarios. A CAPTCHA flow can be served with a 200 response while block or limit decisions can return 403, 413, 451 or 503. Selecting the right semantic code for both API clients and web users improves integration quality.
Logo and SVG usage
Logos, SVG graphics or image content can be embedded inside the HTML inline or as base64. This approach reduces separate asset dependencies and makes producing a self-contained custom page straightforward. The organisation's brand can be added to the page through a custom HTML layout.
File synchronisation
Ready-made DDoS challenge and JS verification files can be tracked through a dynamic file binding mechanism. When a file is updated, the relevant content is reflected to the serving layer. This keeps static pages current without turning each update into a manual service restart operation.
When to use it
Branded block page for a bank
A bank can deploy a custom CAPTCHA or block page with a white/blue theme, corporate logo, localised text and a support link. The reason code is kept hidden from the user while the support team can review the real cause in the logs.
DDoS challenge during a high-traffic e-commerce event
When automated traffic spikes during a campaign period, a countdown-based DDoS challenge page can be shown to real users. After a brief verification step users continue their shopping flow while bot traffic is separated.
Country-specific access message on a government portal
A government agency can return a custom page with a localised explanation for specific access decisions. The user is told in institutional language why access is restricted and which support channel to contact.
JSON block response for an API endpoint
For API services, returning a 403 or 429 response in JSON format is more appropriate than an HTML page. TR7 embeds the reason value in the JSON body through a custom WAAP action, allowing client applications to handle the error programmatically.
Frequently asked questions
Which security decisions support a custom block page?
How can a new language be added to the CAPTCHA page?
Does serving a block page add load to the backend?
Can a JSON error response be returned instead of HTML for API endpoints?
Does the reason code always have to be shown to the user?
Can each application use a different page in a multi-tenant environment?
Make the experience after a security decision part of your brand
Customisable block pages for DDoS, CAPTCHA, bot protection and WAAP actions. Let's walk through how it works on your own setup.