Area: Optimizely CMS
Applies to versions: 10 and higher
Other versions:

Recommendations for ASP.NET security settings

Recommended reading 

After you install and Optimizely website, use the recommendations in this topic for some common ASP.NET-related security areas, and manage these for Optimizely websites.

Weak password account lockout policy and password change functionality

Optimizely uses standard ASP.NET mechanisms for password handling, which lets you configure things like password complexity policies. You also can configure Optimizely to use Windows or Active Directory for authentication, meaning that password changes and lock-out policy is delegated

You should have strong password complexity requirements on user accounts and ensure that any changes to user accounts involves the user’s current password. You also can use a different Membership provider for Optimizely that does not allow for password change. Either subclassing the SqlServerMembershipProvider or using the ActiveDirectoryMembership provider work equally well.

See the following Microsoft references for information about managing membership accounts.

Cross-site request forgery (CSRF)

Optimizely uses a stateless token based pattern for CSRF mitigation. If you intend to add functionality to Optimizely that includes state changing operations then it is recommended that you include CSRF mitigation; ASP.NET provides standard libraries for implementing this. See https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet for more information about preventing cross-site request forgery.

Ineffective session termination

Optimizely uses standard ASP.NET mechanisms for authentication which does not support active logout, and it is basically sessionless. You might extend ASP.NET, but that is not a feature provided by Optimizely. You should use HTTPS for secure communication, because this does not let third parties sniff the session token.

You can extend ASP.NET's FormsAuthentication ticket with active logout, but that is not a feature provided by Optimizely.

Header disclosure

Through the use of IIS and ASP.NET, some informational HTTP headers are added to a response, which might expose security-releated information like ASP.NET and IIS versions. You can modify this using standard ASP.NET techniques; it is not specific to Optimizely and should be dealt with as part of standard application hardening. You can remove the X-AspNetMvc-Version header with a simple set of the MvcHandler.DisableMvcResponseHeader property.

See Removing HTTP Headers for ASP.NET sites for information about how to avoid disclosing server software information through HTTP headers.

Disabling of autocomplete

You should build a custom login page with auto-complete disabled, replacing the default login page. Forms containing user names and passwords, or other sensitive information, should have the autocomplete option disabled on both the form and the sensitive fields.

Vulnerability to clickjacking attacks

You can avoid clickjacking attacks on websites by ensuring that content is not embedded into other sites using frames. Use the X-Frame-Options HTTP response header to defend against clickjacking attacks. This header indicates that the current page should not be loaded in a frame, and through code you can blank the contents of the page if it is framed by another domain.

See the recommendations in The X-Frame-Options response header.

Related topics

Do you find this information helpful? Please log in to provide feedback.

Last updated: Mar 12, 2019

Recommended reading