Slack - Security Development Lifecycle Checklist

APIs
Are you implementing or modifying any APIs?

Access Control Verification

We have ensured that a Guest user / Multi-Channel user / Normal user / Admin user can only use this API as intended
We have ensured that if our API is called by an unauthenticated user / non-permissioned user, that it behaves correctly and
denies access appropriately
When our API needs to be restricted based on a team-scope, user type restriction, or other access control consideration, we
check for those conditions before performing any actions. In an enterprise org, we check for these conditions on all teams

Alert and Warning Messages

Users need to understand the security impact of alert and warning messages to make safe choices. This section contains guidance
on how to make sure that those decisions are clear.

NEAT Guidance (adapted from Microsoft)

Necessary: The user absolutely needs to be presented with a decision for alerts and warnings.
Explained: The user has all of the information to make an appropriate decision.
Actionable: The user has a list of steps to make a good decision in both benign and malicios scenarios.
Tested: This warning has been reviewed by multiple engineers to make sure users understand how to respond to it.

Authentication
Does your code authenticate or authorize users, tokens, sessions, or other?

General
We are only using approved authentication providers, or we are working with the security team on new autentication methods.
We are storing authentication tokens for integrations correctly.
We are not echoing authentication tokens (ours or third parties) into logs.

Cryptography
If You're Typing the Letters A-E-S Into Your Code You're Doing It Wrong.

General
We have read [this humorous short play](https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2009/july/if-youre-
typing-the-letters-a-e-s-into-your-code-youre-doing-it-wrong/)
We are not using weak Cryptography algorithms DES/3DES or weak hash algorithm MD5/SHA1
We are storing the currently used algorithm in addition to the encrypted or hashed text, to allow us to roll forward to different
algorithms in the future (cryptographic agility).
We have ensured implementing encryption does not introduce any denial-of-service conditions (e.g. performing cryptography on
strings longer than 500 characters)
General Guidance
Applies to All Projects: Standard security guidance that all projects, regardless of features, need to follow.

General
We have completed a high-level [STRIDE](https://msdn.microsoft.com/en-us/library/ee823878%28v=cs.20%29.aspx) threat model
of your project or feature. For any potential issues that arise from following this process, please comment and detail them on this
jira card.
We have tagged any bugs filed as a result of items in these checklists with '`security`' label.
Our application is running on machines supported by Operations.
We have thought about the default settings of this feature to ensure they are as secure and de-permissioned as possible.
We have looked at past bug bounty issues (tagged with '`bugbounty`') specific to this feature, functionality, or other similar features
and ensured we're not making similar mistakes.
We have checked for dead code, and deleted it. Less code = fewer bugs!
We have not implemented any user-impersonation functionality. If we have, we have had an in-depth discussion with the product
security team about it
When a user is disabled or deleted, our functionality is not affected at all and we have no additional tasks to perform. (For
instance, when a user is created, and if they interact with our component, we don't need to perform any cleanup on behalf of a
user delete or disable)

Privacy
We only utilize third-party services supported by IT or Operations
We have ensured that error messages don't leak sensitive information (debug/callstack/full objects) to a user

Information Leakage
This project or feature involves operating or displaying user information

General
This feature does not introduce the ability for a non-user (who does not have explicit access) to enumerate or display the
existence of other users or user information
There is no functionality in our feature that returns a raw database entry back to the user

Language - All-Language Questionnaire

These are questions apply to any language, and should be included

General
We are using a company-standard language, or we have checked in with the security team about using another language. Current
supported languages are PHP, JavaScript, Java, C/C++ and Go
We are using the best language for our project/functionality and it is considered supported and well-maintained

Legal & Policy - Legal

Legal needs to make sure we can continue to make good with our customers and contracts. Please reach out to #help-legal if your
team has any issues with the following

Legal Team Questions

We do not employ the use of any proprietary third party code
Our feature does not introduce any new open-source libraries (licensing)
This feature does not introduce any complications to our SLAs for performance (e.g. significant page load times)
Legal & Policy - Policy
Policy needs to make sure we can continue to make good with our customers and contracts. Please reach out to #policy if your team
has any issues with the following

Privacy
This feature does not change the visibility or audience of message content
This feature does not ask for new permissions on a device
This feature does not scan message content or analyze it
This feature does not collect location information
This feature does not import contact information
This feature does not track visitors to measure advertising

Data Practices
This feature reasonably uses / collects data in a way that is expected by our customers
This feature doesn't collect any personally-identifiable-information (phone number, name of a user, email address, message
content, web browsing history, photos, apps downloaded, unique device identifier, etc...)

Terms, Policies, Controls

This feature won't require us to update our Terms of Service

Native Clients - Android

We are developing android application

General
We are not using MODE_WORLD_WRITEABLE or MODE_WORLD_READABLE
We are only requesting the minimum set of permissions necessary in `AndroidManifest.xml`
We are limiting our exported `activity` / `receiver` / `services`
We are only displaying trusted content to `webview`

Native Clients - Client Data Storage

Does your application store data in the client?

General
We are not storing user's password in the client
No sensitive data is included in backups generated by native clients
We are not hardcoding any keys or secrets
We remove user cached data when the user logout

Native Clients - Electron

We are developing electron application

General
We are not using <iframe>
We are only displaying trusted content to `webview`
Native Clients - Logging
Does your application store logs in the client?

General
We are not logging sensitive data (e.g. user password, session token, etc)
We have removed debugging code
We are not logging verbose error or debugging messages

Native Clients - Windows Phone

We are developing Window phone app

General
We are only displaying trusted content to `WebView`

Native Clients - iOS

We are developing iOS application

General
We are not using NSUserDefaults or plist to store sensitive data
We are only displaying trusted content to `UIWebviews`

Parsing - URL Parsing

Does your component build/parse URLs, read/write URLs, or operate with/consume URLs?

General
We are using a url-parsing library to load every url and guaranteeing its validity before operating on it
We know what type of scheme (http/https/ftp) we are expecting, so we are guaranteeing that the scheme is being parsed, and
validated correctly

Parsing - XML
Does your code work with/write/read XML?

General
We are validating user-supplied XML with a schema doc before working on it
We have disabled all routes to [XML External Entity processing](https://www.owasp.org/index.php
/XML_External_Entity_%28XXE%29_Processing) at the parser level
Regular Expressions
Are you utilizing Regex in your application?

General
We are utilizing a built-in library to do data validation, instead of regex (e.g. url parsing)
We have taken every step available to avoid utilizing user-provided regular expressions
We have taken steps to ensure that there are no [denial-of-service scenarios](https://www.owasp.org/index.php
/Regular_expression_Denial_of_Service_-_ReDoS) since we are dealing with user-provided input for regular expressions (e.g.
limiting the character set of allowed characters, length of pattern)

SQL
Our project utilizes a database via SQL

General
We are not writing SQL and are utilizing the already-existing database abstraction functions available in our development
We are utilizing bind variables for any SQL statements, utilizing safe db functions
We are not building SQL statements by using string concatenation

Third-Party & External - Open Sourcing this Project

Are you planning on open-sourcing this library?

Source Code Repository Scrubbing

We have scrubbed the source code repo for secrets?
We have scrubbed the source code repo for history?
We have talked with the Open-Source team to ensure this project is a good candidate for being made public

Third-Party & External - Third-Party Libraries

Does your project introduce or utilize a third-party library?

General
The maintainer of this 3rd-party library has a security policy
We are utilizing the latest available stable version of this library
We have notified the security team about the usage of this library

Third-Party & External - Upgradability

Does this functionality have any considerations when libraries and components around it are updated, e.g for security patches?

General
There is a security plan (documentation, automated testing, and steps for an emergency upgrade of a 3rd party library) and
commitment for upgrading, patching, and ongoing maintenance for this project
We have the ability and support to upgrade this functionality and it's supporting libraries for security incidents on a timeline of 3
days maximum
Web - CSRF
Implementing functionality that causes user actions to happen can sometimes be triggered remotely without the user being aware. If
your functionality is exposed directly on web, please make sure that you are protected against csrf attacks

General
We are using the built-in anti-CSRF framework for our form and action functionality
Every action in our functionality that can be unfortunate for a user to trigger (sending a message, deleting an account), is
protected by an anti-CSRF token

Web - Misc Web

Miscellaneous web issues that should be relevant for any web project

General
We do not take user input from a `GET` parameter and display it in a context that may be confusing to a user, or could convince a
user to perform a malicious action (Text Injection)
All content rendered or injected into the page uses SSL/TLS to avoid Mixed Content issues

Javascript
We have verified the origin when excepting `postMessage()` from other windows
We have verified the targetOrigin when using `postMessage(message, targetOrigin)`
We have verified the syntax of the received message to prevent XSS when excepting `postMessage()` from other windows

Web - Open-Redirection
Do you send users to another url?

General
Since the redirection doesn't need to be arbitrary, and user-controlled, we are utilizing the redirect framework to facilitate the
redirection
We have looked into ways to avoid directing users to arbitrary urls, especially those that are user-controlled, while still retaining
our functionality

Web - Secure Cookies

Do you set cookies in your component?

General
We have forced the use of the `secure` flag if possible
We have forced the use of the `HttpOnly` flag if possible
We have alerted the Policy team to the contents and purpose of this new cookie, and where it will be used
We have ensured that the `domain` being set on this cookie is tightly-scoped to our specific location of functionality
We are not using cookies to store directly-sensitive information (customer information, data)
 Web - XSS
We are rendering content dynamically via DOM or reflecting content with PHP/Smarty

General
We are using standardized formatting libraries for all output of user-provided data
We are using proper `Content-Type` headers when rendering content. e.g. `JSON` should be served with Content-Type:
application/json
We have ensured that user input is not echoed or output unencoded on the page
We have tested user input (things that can be provided by the user - team name, text, etc..) with the value <script>alert(1);
</script> to ensure there is no XSS present

Javascript
We are using the javascript formatting library to properly encode all user-provided data
We are not using .innerHTML, jQuery's $.html(), handlebars' triple curly brace {{{, or other direct-DOM methods with unsanitized
user-provided data

Smarty
We are using the escape filter on all variables being rendrerd for the correct context that the text is being rendered in (inside
HTML vs inside Javascript)

Generated: 2018-12-06 11:02:01.741449