Security/ReviewTemplate

Security Review Pre-Work

Please fill our the short section below prior to the review, and make sure you contact security@mozilla.org to schedule your actual review.

Overview

Describe the goals and objectives of the feature here.

Background links

• feature-tracking bug links
• public specifications (RFC's, W3C specs, IETF Drafts, etc)
• design docs or internal specifications
• data flow or entity relation diagrams
• links to other implementations of the feature

Threats

Please list the top 3 security threats you have considered during the design and implementation of this feature.

• Threat 1
• Threat 2
• Threat 3

What mitigations have you implemented?

---

Topics To Discuss During The Review

Please be prepared to discuss the following topics as they relate to your feature / project. To the degree you can answer some of these questions prior to the review it will speed up the process, but its not a requirement.

Security and Privacy

Provide a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

• Is this feature a security feature?
  • If it is, what security issues is it intended to resolve?
• How are transitions in/out of Private Browsing mode handled?
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
• If any content or UI is displayed to the user, in what context is that content presented? Does it have chrome privileges, for example?
• Does the feature include any new cryptographic functions or other security-critical code?
  • Has this code been reviewed and verified by someone familiar with the theory or principles behind it?

Exported APIs

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc). Explain the significant file formats, names, syntax, and semantics.

• Does it interoperate with a web service?
  • How will it do so (by which protocols or techniques)?
• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
• Does it change any existing interfaces?

Module/Library interactions

• What other modules are used (REQUIRES in the makefile, interfaces)?
• What third-party libraries are used (.so, .dll, source code libraries/modules, etc)?
  • Have these third-party sources been reviewed for security?
  • How will we keep up-to-date with upstream?

Data

• What data is read or parsed by this feature?
  • What types of validation are done on data inputs (e.g., type checking, string decoding/encoding, etc.)?
• What is the output of this feature?
  • What types of normalization or sanitization are performed on data outputs (e.g., data aggregation, string encoding, path canonicalization, etc)?
• What storage formats are used?
  • Who can access the data in storage (for example: is it encrypted with a master password, obfuscated, packed, protected by a filesystem ACL, etc)?

Reliability

• What failure modes or decision points are presented to the user?
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

Configuration

• Can the end user configure settings (via UI, about:config, or environment variables)?
• Are there build options for developers (e.g. #ifdefs, ac_add_options)
• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects

Are there related projects in the community?

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
• Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

Review comments

Notes made during the review will be recorded here.