Security
Form settings, SQL injection checks, security headers, etc.
The Security node contains various settings related to security, divided into sections as described below.
Form
The Form settings are used to activate antispam on forms. Once activated, a set of hidden input fields are generated when a form is rendered. If these fields are filled (typically by bots), or if other antispam checks fail, the form submission is regarded as spam and blocked.
The following settings are available:
| Setting | Use | Notes |
|---|---|---|
| Activate antispam functionality – Forms | Activates antispam on Forms for Editors forms | Adds automatic hidden captcha fields and performs bot checks when forms are submitted. Requires the hidden antispam fields to be present in the form templates. |
| Activate antispam functionality – Users | Activates antispam on Extranet forms | Adds automatic hidden captcha fields and performs bot checks when users are created. Requires hidden antispam fields in the user creation template. |
| Activate antispam functionality – Comment | Activates antispam on comment forms | Adds automatic hidden captcha fields and performs bot checks when comments are submitted. Requires hidden antispam fields in the comment edit template. |
| Send notification to e-mail | Enter an email address | When spam is detected, an email containing the blocked submission data is sent to this address. |
| Seconds before post | Enter value in seconds (default: 2) | Forms submitted faster than this threshold are marked as spam. |
| Allowed submits from same IP | Enter a value (default: 15) | If more than this number of submissions are made from the same IP address, they are marked as spam. |
| IP submit timeframe in hours | Specify timeframe in hours (default: 24) | The time window used when counting submissions from the same IP address. |
| Disable extended checks | Enable to disable extended checks | Turns off timing checks and IP submission limits. |
| Enable hCaptcha | Enables hCaptcha validation on forms with antispam enabled | Adds an hCaptcha challenge and verifies the response server-side when a form is submitted. Requires hCaptcha keys to be configured. |
| hCaptcha site key (public) | Enter the hCaptcha site key | Public key used to render the hCaptcha challenge in forms. Safe to expose in frontend markup. |
| hCaptcha secret key (private) | Enter the hCaptcha secret key | Private key used server-side to verify hCaptcha responses. Must be kept confidential. |
hCaptcha
hCaptcha is an external bot-detection service that complements Dynamicweb’s built-in antispam mechanisms (hidden fields, timing checks, IP limits).
When hCaptcha is enabled, Dynamicweb automatically injects an hCaptcha widget into forms where antispam is active and validates the hCaptcha response when the form is submitted.
To use this feature you need to create an hcaptcha account:
- Go to https://dashboard.hcaptcha.com
- Create an account and register your site/domain.
- Configure the site for passive / non-interactive behavior.
- Copy the site key and secret key into the corresponding Dynamicweb settings.
Once activated, hcaptcha works in the following manner:
- hCaptcha runs automatically and invisibly in the background
- No checkbox or user interaction is normally required
- A verification token is generated and submitted with the form
- If verification fails or the token is missing, the submission is treated as spam
As such, this security feature offers improved protection against automated bots and scripted submissions, without impacting the user experience. No templating required beyond existing antispam support. It does not replace other DynamicWeb antispam checks, it does not guarantee that all spam is blocked, and it does not display a visible hCaptcha challenge unless hCaptcha determines it to be necessary.
Consider using hCaptcha when you have:
- Public-facing forms exposed to spam or abuse
- User registration and comment forms
- High-traffic forms where hidden-field and timing checks alone are insufficient
Tip
hCaptcha requires outbound HTTPS access from the application to hcaptcha.com for verification. This is always possible in Dynamicweb Cloud.
To test hCaptcha in local development environment, refer to hCaptcha documentation: https://docs.hcaptcha.com/#local-development
Troubleshooting hCaptcha
If form submissions are unexpectedly blocked after enabling hCaptcha, use the table below to identify and resolve the issue.
| Issue | Symptoms | Checks / Explanation | Resolution |
|---|---|---|---|
| Forms are blocked immediately after enabling hCaptcha | - All form submissions are rejected. - Users report that forms “do nothing” or return errors. - Security logs show Missing hCaptcha token or hCaptcha verify error. |
Checks: 1. Verify that Enable hCaptcha is set to true and both keys are configured.2. Confirm that the hCaptcha site key and secret key belong to the same hCaptcha site. 3. Check that the configured domain in hCaptcha matches the site domain exactly (including subdomains if used). |
- Correct the keys or domain configuration. - As a temporary workaround, disable Enable hCaptcha to restore form submissions immediately. |
| hCaptcha is visible or overlaps the form | - A visible hCaptcha widget appears. - The widget overlaps form elements. |
Explanation: - This usually indicates that the hCaptcha site is configured for interactive mode. |
- Update the hCaptcha site configuration to use passive / non-interactive behavior. - Ensure that “Always challenge” or forced checkbox modes are disabled in the hCaptcha dashboard. |
SQL injection
The SQL Injection Check settings are used to tweak or disable our built-in SQL injection check security measures. When the SQL injection check is active - the default state - everything looking like an injection attempt will result in a temporary ban, and optionally a longer IP ban. The list of banned IPs can be found under \Files\System_BannedIps.txt with additional information about the cause of the ban. Only SQL injection attempts will return in IP bans – other forms of attack, such as cross scripting attempts, will only result in 404 on subsequent tries.
The following settings are available:
| Setting | Value | Notes |
|---|---|---|
| Disable SQL injection check | True/False | Disables SQL injection checks. We strongly advise against this |
| Do not ban IPs when injection is detected | True/False | Keeps SQL injection checks but turns off IP bans |
| Days to ban IP when injection is detected | Integer | Enter a ban length – defaults to 30 |
| Ignore the following form field names | Comma-separated list of field names | Disable SQL injection checks on specific fields |
| Whitelist IPs | Comma-separated list of IPs | |
| Send notification to e-mail | List of emails | The specified email addresses will receive a notification when SQL injection attempts are detected. Use comma to separate email addresses |
Security headers
The Security headers section allows you to enable or disable several different security-specific headers in http request headers:
| Setting | Value | Notes |
|---|---|---|
| Enable 'X-XSS-Protection: 1; mode=block' header | True/false | Blocks rendering if supporting browsers detect XSS attacks |
| Enable 'X-Content-Type-Options: nosniff' header | True/false | Instructs browsers to use mime-type from response headers |
| Enable 'X-Frame-Options: sameorigin' header | True/false | Prevents browsers from rendering a page in a frame, iframe, embed or object element on other websites |
| Referrer polity | Select a referrer policy | Referrer-Policy: no-referrer-when-downgrade is browser |
| Enable 'Strict-Transport-Security: max-age=(expire-time)' header (HTST) | True/false | Default expire-time is 2592000 seconds, which is 30 days. This header will cause problems if SSL certificate expires |
| Strict-Transport-Security max-age in seconds | Integer | The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS. Default is 2592000 |
| Custom HTTP response headers | List of custom HTTP response headers | Use the format 'header-name: header-value'. Separate headers with [;]. Use for i.e. Content-Security-Policy headers |
Debugging
The Debugging section can be used to disable various debugging & exception-related features:
| Setting | Used for | Notes |
|---|---|---|
| Do not allow debug=true | Disables the use of ?debug=true, dbstat=true etc. for users not logged in to the administration | |
| Throw exception from content modules | Throws a .NET exception if ContentModule.GetContent() has exceptions instead of rendering the exception on the page. Requires pool recycle | |
| Throw exception for templates | Throws a .NET exception if a Razor template has any errors at compile or runtime instead of rendering the exception on the page. Requires pool recycle | |
| Display friendly error message for templates and apps | Displays a friendly error message in frontend when a module or template exception occurs. Disables regular exceptions | |
| Friendly error message | Specify the friendly error messaged enabled using the previous setting |
Image validation
The Image validation settings control how GetImage.ashx - the DynamicWeb image handler - processes on-demand image requests. Without restrictions, an attacker could generate millions of unique images by varying parameters such as width, height, format, and quality, which may cause a denial-of-service (DoS) situation. These settings allow you to define limits that reduce the attack surface and server load.
The following settings are available:
| Setting | Value | Notes |
|---|---|---|
| Enable image validation | True/False | Activates validation and enforcement of the settings below. |
| Minimum image width | Integer (px) | Requests smaller than this will be adjusted upwards. Prevents tiny images from triggering excessive file variations. |
| Minimum image height | Integer (px) | Requests shorter than this will be adjusted upwards. |
| Minimum image quality | Integer (1–100) or -1 for WebP lossless | Requests lower than this will be adjusted. Helps avoid very low-quality variations. |
| Maximum image width | Integer (px) | Requests wider than this will be capped. Prevents oversized image generation. |
| Maximum image height | Integer (px) | Requests taller than this will be capped. |
| Maximum image quality | Integer (1–100) or -1 for WebP lossless | Requests higher than this will be adjusted. |
| Allow WebP lossless compression | True/False | Controls whether Quality = -1 (lossless WebP) is permitted. If disabled, requests fall back to lossy quality. |
| Allowed image widths | List of integers (px) | If defined, only these widths are permitted. Other values are normalized to the nearest allowed. |
| Allowed image heights | List of integers (px) | If defined, only these heights are permitted. |
| Allowed image qualities | List of integers | If defined, only these quality values are permitted. |
| Allowed image parameters | List of parameter names | Explicitly whitelists query parameters such as Format, Quality, Ratio, crop, etc. Parameters not in the list are rejected. Image, Width, and Height are always allowed. |
When these settings are configured, all requests to GetImage.ashx are validated against the configured limits:
- Disallowed parameters return 400 Bad Request
- Values outside min/max ranges are automatically normalized
- If allowed lists are configured, invalid values are rounded to the nearest allowed option
- Administrators logged into the backend can bypass validation with
skipValidation=true(useful for testing)
Tip
An example configuration could look like this:
- Max width: 2000
- Max height: 2000
- Allowed widths: 500, 1000, 1500, 2000
- Allowed parameters:
Format, Quality, crop, Ratio
This ensures that only controlled sets of images can be generated, preventing attackers from exhausting system resources with arbitrary requests.
DynamicWeb support
The Restrict access for support users setting allows you to remove angel-access from the solution. This is the access used by support staff to login to a solution when investigating issues.
Backend access
The Backend access security settings are used to whitelist and blacklist specific IPs.
- When a whitelist is configured, only the specified IPs are allowed to connect to the /Admin login page
- When a blacklist is configured, the specified IPs are not allowed to connect to the /Admin login page
Both of these lists support multiple formats:
- Exact IPs (192.168.1.100)
- CIDR notation (10.0.0.0/24)
- IP ranges (192.168.1.1-192.168.1.50)
- Wildcards for IPv4 (192.168.1.*)
Please note that blacklist filtering is applied first, followed by whitelist filtering if whitelist entries exist.