Security/ReviewTopics

These are some questions we might ask during a security review.

Security

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?
  • Do your tests include both should-be-allowed and should-be-disallowed cases?
• 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?

Privacy

• Does the feature expose information that could strengthen fingerprinting?
• Does the feature cache or store data that could strengthen super-cookies?
• How are transitions in/out of Private Browsing mode handled?
• How is "Clear Recent History" handled?

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)?

C and C++

• Did you minimize and isolate use of low-level constructs (manual allocation, manual refcounting, union tricks such as bit-stealing, and pointer arithmetic)?
• Does your code build without warnings?
• Are new C++ classes annotated for Mozilla's dehydra analyses?
• Do you use CheckedInt where integer overflows could be an issue?
• Does the code use assertions to make it easier to catch bugs?
• Are the safety-critical invariants documented?
• What would make you more confident in the code's safety?
• When calling scripts (or firing events), is it safe to run scripts? Are you holding any raw pointers that might disappear on you? (Smaug's area of expertise)

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?

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?