HomeDev GuideRecipesAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Security

Learn how CMS 13 addresses common security concerns from authentication to transport layer protection.

Optimizely Content Management System (CMS) provides defense-in-depth security across authentication, data protection, and transport. Login security is based on ASP.NET Core Identity, which handles user and role management for CMS.

CMS addresses the following common security concerns:

  • Authentication and authorization – Authentication in CMS is based on the ASP.NET Core framework for users and roles. CMS uses a standard API, so creating a custom provider for any user database or third-party provider is straightforward.
    📘

    Note

    Where and how user credentials are stored depends on the authentication provider. Separating authentication from authorization increases flexibility. Delegating security operations to a separate provider machine also increases scalability. CMS supports single sign-on and federated claims-based authentication.

  • Injection protection – CMS code uses parameterized APIs so that injection attacks cannot succeed from untrusted input. No code paths in CMS pass untrusted data to XML-related calls.
  • Cross-site scripting (XSS) – CMS filters and validates user input to prevent XSS issues. Optimizely applies HTML encoding to outgoing data to block XSS attacks. The editorial and administrative interfaces accept HTML and scripts for content authoring. CMS relies on authorization to ensure that only trusted users provide content.
  • Broken authentication and session management – The CMS authentication system is based on the ASP.NET Core framework for users and roles. CMS does not rely on session data, which improves security, scalability, and performance because browser sessions do not require server affinity.
  • Insecure direct object references – In CMS, references pass through at least one layer of indirection with access controls in place.
  • Cross-site request forgery (CSRF) – CMS has a CSRF prevention mechanism that detects forged requests for system pages. The event validation mechanism in ASP.NET is also enabled for these pages. Optimizely provides optional anti-forgery and event validation for site pages.
  • Security misconfiguration – CMS configuration is designed with secure by default in mind. Strong security requires a secure configuration defined and deployed for the application, frameworks, web server, database server, and platform. Define, implement, and maintain these settings because many defaults are not sufficiently secure.
  • Insecure cryptographic storage – CMS uses verified, strong algorithms. A small part of the CMS configuration may contain sensitive information, such as the ConnectionStrings section. Encrypt this information with the .NET framework encryption features. Optimizely stores other system assets in a SQL database with full support for the database native encryption.
  • Failure to restrict URL access – Sensitive areas of CMS, such as the edit and admin UIs, are protected by default. Public-facing web page content is subject to content-based authorization. CMS never relies on security through a secret URL.
  • Transport layer protection – The most common sensitive information on the network is user credentials. CMS fully supports SSL (HTTPS protocol).
  • Unvalidated redirects and forwards – CMS minimizes redirects because they pose security and performance risks. Existing redirects are based on internal data or sanitized information.
  • Virus protection – CMS relies on third-party products for virus protection. Optimizely never executes files uploaded to the asset manager, preventing viruses from spreading.