DynamicWeb 10 Security

DynamicWeb 10 is a web application serving web pages on a webserver. Overall there are 2 areas of security when hosting a DynamicWeb solution:

Infrastructure tier security (Firewall, Windows, IIS, SQL-Server, ASP.NET and related technologies)
Application tier security (The DynamicWeb application).

This document primarily covers the application tier security. For infrastructure tier security, please refer to the hosting provider.

Below is a comprehensive view of the security measures and best practices implemented in DynamicWeb 10, incorporating information from official security reports, Microsoft security practices, and third-party security partnerships.

Infrastructure tier security

DynamicWeb relies on best-in-class infrastructure security for its web hosting and internal IT-systems, including:

Firewalls
Secure server configurations
Stringent access control mechanisms
MFA authentication and secure access through encrypted VPN
Cloud operated tools and services guarded by vendor security

In our cloud environment, we’ve implemented a cloud-native endpoint protection and response platform that continuously monitors every virtual machine and container. By leveraging advanced behavioral analytics and machine-learning models, it identifies suspicious processes and anomalous activity in real time, automatically isolating or remediating compromised workloads before they can spread. This automated, host-level security layer gives us full visibility across our infrastructure, accelerates incident response, and significantly reduces manual intervention—helping ensure our cloud remains resilient against the latest threats.

These measures help protect against unauthorized access while maintaining compliance with GDPR and other data privacy laws.

In addition, ECIT serves as our external security consultant: they deliver security-awareness training and have deployed a real-time security monitoring and threat-detection platform across our devices to continuously monitor user behavior and flag any unusual activity.

Application tier security

At the application level, DynamicWeb 10 has several integrated defenses designed to secure both the frontend and backend:

User Access Control (UAC)

DynamicWeb 10 implements multiple layers of User Access Control (UAC), which defines the scope of permissions:

Anonymous users can browse the public areas of the site.
Authenticated users have access to specific areas based on assigned roles.
Administrators have full access to both frontend and backend interfaces, ensuring secure content management.

Security against common attacks

DynamicWeb is equipped to handle several common web application vulnerabilities by employing mitigation strategies for:

Cross-Site Scripting (XSS)
SQL Injection
HTTP Header Injections
Cookie Attacks

These safeguards are regularly tested using automated tools, which automates the detection of vulnerabilities related to SQL injections.

Secure coding practices

DynamicWeb aligns with Microsoft's secure coding guidelines, ensuring that developers use best practices in preventing vulnerabilities during the software development lifecycle. In Visual Studio, developers are required to:

Run Static Code Analysis using built-in tools such as SNYK and Microsoft's Code Analysis to detect and resolve vulnerabilities early in the development process.
Follow coding rules related to key security areas, including encryption, secure authentication, and data validation.

Moreover, compliance with OWASP Top 10 guidelines ensures that our application remains protected against the most prevalent security risks.

Security bug fix policy

To ensure continuous protection, DynamicWeb follows a well-defined security bug fix policy that categorizes vulnerabilities based on severity:

Critical vulnerabilities are fixed within 2 business days.
High and Medium severity issues are resolved within 5 to 20 business days, depending on the complexity.

Security reports, including any vulnerabilities discovered, are handled through an internal escalation process, and all reported issues are logged within Azure DevOps to track and resolve them efficiently.

Security report handling

DynamicWeb encourages responsible disclosure of security vulnerabilities and has a formalized process for security report handling:

Submission: All security reports can be submitted through our Partner Support system or by directly contacting our team.
Verification: Each report is assessed and verified for its validity.
Response: Critical vulnerabilities are addressed as a matter of urgency, with fixes deployed as part of regular maintenance releases.

Third-party security audits

In addition to internal security measures, DynamicWeb partners with ECIT for external security audits, vulnerability scanning of internal systems, and employee training. ECIT's services ensure that our systems are continuously monitored for vulnerabilities, and their expertise in managing IT security helps bolster our internal processes.

The EU NIS2 Directive raises the bar for cybersecurity across affected sectors, with a strong emphasis on strong authentication, access control, and keeping software up to date. DynamicWeb 10 ships a set of login and account-protection features designed so customers in scope of NIS2 — and any customer that simply wants a defensible login posture — can meet those expectations without custom development.

For the underlying screens and configuration, see the security settings and password security settings.

Each user-area can be configured with one of four login modes, applied across the frontend authentication flow:

Normal — username and password
TOTP — Time-based One-time Passwords, paired with an authenticator app
Magic links — passwordless email-based login: the user requests access and signs in via a one-time link delivered by email
MFA — password plus a one-time code delivered out-of-band (email), with code expiration and a cap on failed verification attempts

Magic-link and MFA codes are single-use: a successful verification removes the code from the cache so it cannot be replayed.

External identity providers (SSO)

DynamicWeb supports single sign-on against external identity providers, including:

Microsoft Entra ID (Azure AD)
Google
Okta
Other OAuth2 / OpenID Connect providers, including partner-built providers added through the extensibility model

External providers can be configured to link a new external login to an existing account by email, so users who already exist in DynamicWeb can adopt SSO without manual account-merging.

Account protection

Beyond the login mode itself, DynamicWeb enforces several protections against brute-force and credential-stuffing attacks:

Failed-login limit — when the configured number of failed attempts is reached within the failure window, the account is automatically blocked for a configurable blocking period. Both the threshold and the windows are administrator-controlled in the password security settings
Account-block check before authentication — blocked accounts are rejected before the password is even evaluated, so a blocked account does not leak information about credential validity
Password-length validation — input is bounded before hashing, preventing pathological inputs from being processed
Password expiration — when PasswordExpireDays is configured, passwords past the expiry date are refused and the user is prompted to change them
Password hashing — passwords are stored hashed, not in clear text, and the legacy clear-text path has been removed from the platform

Impersonation and user switching

For B2B scenarios where one user needs to act on behalf of another (for example, a sales rep placing an order for a customer):

Impersonation requires explicit authorization through UserImpersonationService.CanImpersonate — it is not a global capability granted to any signed-in user. Both the start and stop of an impersonation session go through the authentication pipeline and emit notifications, giving administrators a hook for audit logging
User switching between accounts that share a username (legacy multi-shop scenarios) is similarly gated through the authentication handler rather than handled client-side

These flows are designed so that elevated actions are auditable and reversible, which is the substantive expectation behind NIS2's access-control requirements.

Notifications and auditing

Every login event — OnBeforeExtranetLogin, OnExtranetLogin, OnExtranetLoginFailed, OnBeforeExtranetLogOff — emits a notification on the DynamicWeb notification bus. Customers can subscribe their own auditing, SIEM forwarding, or anomaly detection without modifying core code, which is how most NIS2-driven logging requirements are typically met in practice.

Secure email delivery for one-time codes

One-time codes used for MFA and magic-link login are delivered via the platform's mail subsystem, which is built on MailKit with TLS support.

Keeping the platform up to date

NIS2's expectation that software is kept current is supported by DynamicWeb's release policy — monthly minors flow through release rings, critical and security fixes are hotfixed ahead of cadence, and security fixes are back-ported to any milestone released in the past 12 months under the security bug fix policy. Staying on a supported ring is the operational side of this control.

Together, these measures reduce the risk of unauthorized access and give organizations the building blocks to meet the access-control, authentication, and logging expectations in NIS2 without leaving the platform.

Table of Contents