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.
TR7 manages block pages through ready-made templates, EJS rendering, native response serving and reason code injection.
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.
CAPTCHA pages are built with EJS templates. Theme, size, background colour, text colour and the language dictionary can all be applied at render time.
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 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.
TR7 Block Page Customization centrally manages HTML, CAPTCHA, challenge and JSON responses for different WAAP decisions.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
Reliable block page delivery requires coordinated planning across file serving, language addition, status code selection, dynamic variables and static asset management.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Customisable block pages for DDoS, CAPTCHA, bot protection and WAAP actions. Let's walk through how it works on your own setup.