Security Checklist

[leplatrem]

Risk Management

• The service must have performed a Rapid Risk Assessment and have a Risk Record bug (SVC-RRA).

Infrastructure rules

• Access and application logs must be archived for a minimum of 90 days
• Use Modern or Intermediate TLS (INFRA-TLS)
• Set HSTS to 31536000 (1 year) (INFRA-HSTS)
  • strict-transport-security: max-age=31536000
• Set HPKP to 5184000 (60 days) (INFRA-HPKP)
  • Public-Key-Pins: max-age=5184000; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis=";
    • Start with max-age set to 5 minutes (max-age=300) and increase progressively
    • The first two pins are for Digicert EV and DV roots, the last two are for Let's Encrypt X3 and X4 intermediates (LE is only used for backup)
  • If the service is not hosted under services.mozilla.com, it must be manually added to Firefox's preloaded pins.
• If service has an admin panels, it must:
  • only be available behind Mozilla VPN (which provides MFA) (INFRA-ADMINVPN)
  • require LDAP authentication (INFRA-ADMINLDAP)
  • enforce a two-man rule on sensitive changes (INFRA-2MANRULE)

Coding rules

The following rules apply to all web applications: api and websites.

• Sign all release tags, and maybe commits as well (APP-COMMITSIG)
  • Developers should configure git to sign all tags and upload their PGP fingerprint to https://login.mozilla.com
  • The signature verification will eventually become a requirement to shipping a release to staging & prod: the tag being deployed in the pipeline must have a matching tag in git signed by a project owner. This control is designed to reduce the risk of a 3rd party GitHub integration from compromising our source code.
• Publish detailed logs in mozlog format (APP-MOZLOG)
  • Business logic must be logged with app specific codes (errno)
  • Access control failures must be logged at WARN level
• Must have a CSP with (APP-CSP)
  • a report-uri pointing to the service's own /__cspreport__ endpoint
  • web APIs should set default-src to none, disallowing all content rendering
  • if default-src is not self, frame-src should be none or only allow specific origins
  • no use of unsafe-inline or unsafe-eval
• User data must be escaped for the right context prior to reflecting it (APP-ESCAPE)
• Web APIs must set a non-HTML content-type on all responses, including 300s, 400s and 500s (APP-NOHTML)
• All SQL queries must be parameterized, not concatenated (APP-SQL)
• Apply sensible limits to user inputs, see input validation (APP-INPUTVAL)
• When managing permissions, make sure access controls are enforced server-side (APP-ACL)
• Set the Secure and HTTPOnly flags on Cookies, and use sensible Expiration (APP-SECCOOKIE)
• Keep 3rd-party libraries up to date (APP-DEPS)
  • Use NSP or [GreenKeeper](https://greenkeeper.io/ Greenkeeper) for NodeJS applications
  • Use pip --outdated or requires.io for Python applications
• If handling cryptographic keys, must have a mechanism to handle monthly key rotations (APP-KEYROT)
  • All keys must be rotated quarterly.
  • Keys used to sign sessions don't need a rotation mechanism if destroying all sessions is acceptable during.

Additional websites requirements

The following coding rules only apply to websites, not web apis.

• Never store passwords, use Firefox Accounts (APP-IDP)
• Forbid Mixed content, always use HTTPS (APP-MIXCONTENT)
• Must have CSRF tokens and manually excluded specific forms (APP-CSRF)
• Should consider having checksums for 3rd-party content via SRI (APP-SRI).
  • Trusted 3rd parties, like Google Analytics, don't need SRI. Use your best judgment to decide if a 3rd party script is trustworthy (and assume it is not).
• Set the following security headers (APP-HEADERS)
  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection
• Host user uploaded content on a separate domain (e.g. FxA avatar images on firefoxcontent.com, bug attachments on bug.bmoattachments.org)
• Forbid the use of third party resources (GA, optimizely, ...) on sites that have privileges permissions in Firefox (AMO, testpilot)

Data rules

• When storing sensitive user data (like browsing history) on Mozilla servers:
  • Anonymize it (similar to Tiles) (DATA-ANON)
  • Encrypt it client-side (similar to Sync) (DATA-CRYPT)
  • If user data must be stored non-anonymized and in clear text, you must talk to the security and legal teams about it.
• If the service pushes data to Firefox, like when distributing blacklists or pushing updates, cryptographic signatures must be used. (DATA-SIGN)
  • Addons must use standard AMO signing (APP-SIGNING)
  • Code & Conf must use Content-Signature via Autograph (DATA-SIGNING)

---

imported from mozilla-services/kinto-dist#108