Security Requirements for Content Management Systems

Summary

Contents

This document outlines security requirements for Content Management Systems that are developed by vendors and hosted by Google.

Definitions

Code

For the purposes of this document, "code" is any component that affects the control flow of the server-side or client-side execution of a page. This includes all code in a server-side language (e.g., Python, Java, Go), all client-side code (JavaScript), and any templating languages (e.g., Django templates, Jinja2, AngularJS, or Soy templates).

Security Requirements

General

A partner-developed CMS must comply with all requirements at https://partner-security.withgoogle.com/docs/, including the Web Application Security Requirements and the Outsourced Software Development Requirements. This section describes additional CMS-specific requirements.

No sensitive domains

The CMS should not serve content on sensitive domains, such as *.google.com, *.youtube.com, *.gmail.com, *.withgoogle.com, etc. If you are not sure whether a particular domain is considered sensitive, contact the Google security team.

HTTPS only

Both the CMS administrative interface and the content itself must be served only by HTTPS.

Separate content and code

Content and code editing should be separated: it should be possible to create and update content without affecting any templates or modifying any code. Mixed updates (containing both templates and content) must be treated as code changes. Templates must be written using a templating system that supports strict contextual auto-escaping (e.g., Go HTML, Soy, AngularJS, etc.).

Code must go through standard review

Code must be reviewed by Google prior to deployment. All changes must be recorded, and the names of  the author and approver must be included. (Ideally, changes should be recorded through a standard Google versioning system.)

Audit trail/revisions

Revisions of both code and content must be stored, along with the author and timestamp of each revision. If Google’s version control systems are used, this information will be automatically included.  Content changes may be tracked in any system that's appropriate for the design of the CMS (Datastore, Cloud Storage, Bigtable, etc.).

Approval workflow for content publishing

To protect against defacement, the CMS must support an approval workflow. The workflow should require approval (prior to publishing) by a user other than the initial author. The default behavior of the CMS should be to enforce approval; however, in cases where additional risk is acceptable and approved by Google, it should be possible to disable the approval requirement.

Managed by Google

The CMS itself (that is, the application that provides the editing functionality) must be built on  Google infrastructure (Borg, App Engine, etc.) and must be managed exclusively by Google. Access to the CMS editing interface itself must also be managed exclusively by Googlers, and restricted to only be accessible via trusted devices (hosted on *.googleplex.com).

Content served from Google-controlled infrastructure

All content for the CMS must be served from fully Google-controlled and -managed infrastructure. This includes App Engine, Cloud Storage, and other options. No third-party serving or CDN infrastructure may be used.

Content served from a static content system

For stability and performance reasons, content should be served from a system designed for large-scale serving of static content. This includes Google Cloud Storage (GCS) buckets and AppEngine using the static_files or static_dir options. If business requirements dictate, other serving systems may be used, provided they meet the other security requirements outlined in this document.

No scripts sourced from third-party providers

The CMS should be self-contained and must not source any scripts from external sources or third-party providers. Any third-party integration via an API must be approved by the Google security team prior to its inclusion.

Use of Content Security Policy

Both the administrative interface and the served content should be served with a Content-Security-Policy HTTP header that has been approved by the Google security team. This policy must not be editable by end users and must be included in the code underlying the CMS.  The policy must not contain the unsafe-inline keyword and should not contain the unsafe-eval keyword.

Risks and most common threats

Cross-site scripting

Cross-site scripting is the most obvious risk to a CMS. Requiring review for code changes and separating content and code changes will help to guard against XSS. A well-designed CSP and domain separation will help mitigate the impact of a possible XSS attack.

Unauthenticated updates

Google requires authentication for the CMS administrative interface, to help protect it against remote attack. Additionally, logging the source and delta of changes will help you determine the cause of any unwanted internal changes.