CMS Web Application Security Overview

Overview

Bloomreach Content is designed as a secure web application. It implements established security practices to reduce risk and prevent unauthorized access.

External security audits are conducted regularly. Feedback from these audits is used to improve the security posture of the CMS.

Security Features

This section summarizes key security features in Bloomreach Content. Each feature addresses common web application security risks and can be configured as needed.

Clickjacking Protection

A clickjacking attack tricks users into performing unintended actions, such as submitting credentials to an untrusted site. Bloomreach Content prevents clickjacking by blocking the CMS from being framed in pages with a different host origin.

CSRF Protection

From http://www.veracode.com/security/csrf:

"Cross-Site Request Forgery (CSRF) is an attack outlined in the OWASP Top 10 whereby a malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices."

CSRF protection is enabled by default in Bloomreach Content. The CMS checks the Origin HTTP header for cross-domain requests to Wicket components. This mechanism is similar to Wicket's CsrfPreventionRequestCycleListener, with modifications to support operation behind proxies such as httpd.

To allow specific domains to make cross-origin requests to the CMS, configure the allowed domains in the CMS web.xml file.

For brXM v15.x:

<context-param>
  <param-name>accepted-origin-allowlist</param-name>
  <param-value>example.com, example.org</param-value>
  <description>The allowed domains for cross origin requests</description>
</context-param>

For brXM v14.x:

<context-param>
  <param-name>accepted-origin-whitelist</param-name>
  <param-value>example.com, example.org</param-value>
  <description>The allowed domains for cross origin requests</description>
</context-param>

The param-value is a comma-separated list of allowed domains. Any Origin header matching example.com or example.org is accepted. Subdomains are also permitted, so www.example.org is included.

Note: In version 14.x, the parameter name is accepted-origin-whitelist. This name is replaced by accepted-origin-allowlist in version 15.0 and later. The legacy parameter remains available in 14.x for backward compatibility.

CRLF Injection Protection

From http://www.veracode.com/security/crlf-injection:

"CRLF refers to the special character elements 'Carriage Return' and 'Line Feed'. These elements are embedded in HTTP headers and other software code to signify an End of Line (EOL) marker. Many internet protocols, including MIME (e-mail), NNTP (newsgroups) and more importantly HTTP use CRLF sequences to split text streams into discrete elements. Web application developers split HTTP and other headers based on where CRLF is located. Exploits occur when an attacker is able to inject a CRLF sequence into an HTTP stream. By introducing this unexpected CRLF injection, the attacker is able to maliciously exploit CRLF vulnerabilities in order to manipulate the web application's functions."

Bloomreach Content wraps responses in a ResponseSplittingProtectingServletWebResponse. If CRLF characters are written to response headers, the server returns an error, preventing CRLF injection attacks.

Session Fixation Protection

Session fixation occurs when a server identifies a session using a session ID from the URL, allowing attackers to hijack sessions. To prevent this, disable URL rewriting in your servlet container.

In Tomcat 7, add the following to your web.xml:

<session-config>
  <tracking-mode>COOKIE</tracking-mode>
</session-config>

Warning: If you use a servlet container other than Tomcat, this setting may not be supported. Consult your container's documentation for equivalent configuration.

Password Security

You can enforce minimum password strength and password expiration policies in Bloomreach Content.

Refer to CMS login page configuration for guidance on securing the login page. This includes disabling form field autocompletion, enforcing secure cookies, and restricting CMS access to authorized users.

Additional Protections

CMS internal details are not exposed in error responses when server-side errors occur.
By default, script tags submitted through the CMS editor are removed.