Security Checklist

[jvehent]

I'm creating the checklist here because it seems to be the most appropriate location for it. @mostlygeek & @jasonthomas : could you please go through the items in the checklist and create issues as needed?

Risk Management

• [x] 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
• [x] 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)
  • [x] 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:
  • [x] only be available behind Mozilla VPN (which provides MFA) (INFRA-ADMINVPN)
  • [x] require LDAP authentication (INFRA-ADMINLDAP)
  • [x] enforce a two-man rule on sensitive changes (INFRA-2MANRULE)

Coding rules

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

• [x] 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.
• [x] 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)
• [x] Web APIs must set a non-HTML content-type on all responses, including 300s, 400s and 500s (APP-NOHTML)
• [x] All SQL queries must be parameterized, not concatenated (APP-SQL)
• [ ] Apply sensible limits to user inputs, see input validation (APP-INPUTVAL)
• [x] 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.

• [x] Never store passwords, use Firefox Accounts (APP-IDP)
• [x] Forbid Mixed content, always use HTTPS (APP-MIXCONTENT)
• [ ] Must have CSRF tokens and manually excluded specific forms (APP-CSRF)
• [x] 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] X-Content-Type-Options
  • [x] X-Frame-Options
  • [x] X-XSS-Protection
• [x] Host user uploaded content on a separate domain (e.g. FxA avatar images on firefoxcontent.com, bug attachments on bug.bmoattachments.org)
• [x] 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)

[mostlygeek]

@jvehent for things that don't apply to kinto-dist, do you prefer we just delete it from your original comment or just mark it as done?

[jvehent]

Marking them as done is probably better, that way we can keep the full list.

[leplatrem]

moved to https://github.com/mozilla/remote-settings/issues/153