Standards for Application Development
Content
Standards for Application Development
Last edited
By
Notes
Standards for Application Development – by @snipeyhead
Purpose:
This document outlines the minimum set of standards for environment, coding standards, security and privacy for all applications developed by [COMPANY NAME], or for [COMPANY NAME] through contractors.
Documentation:
Inline code documentation should be provided inline using phpDoc style commenting. http://www.phpdoc.org/ Additional documentation regarding special requirements or instructions for deployment should be included in a detailed README document and supplemental documentation.
Development/Staging:
Code should be written to intelligently detect whether the environment is development, staging or production based on IP or domain name. The domain names and IP addresses should be easily accessible in a configuration file. Detection code and virtual host configurations should fail to production to prevent accidental exposure of the development or staging environments. Development, staging and QA environments should be restricted by IP address and/or username+password authentication so that non-production environments are never exposed to the public. For Facebook pages and applications, development versions of pages should remain unpublished, and applications should remain sandboxed at all times. Applications and pages that will eventually be production versions should be unpublished/sandboxed until launch. Live data that includes real user PII should never be used in test, staging or QA environments. While it is critical to use realistic data in testing environments, actual personally identifiable information should be obfuscated or altered in such a way that it never reflects actual user data. (Example: rewrite all user telephone numbers to reflect randomized digits.) Penetration and vulnerability assessments will be performed at every development milestone, and developers should be load-testing throughout the course of development with realistic database data to quickly identify bugs that could cause issues under stress. Unit tests should be performed on every Git push to limit the amount of time between bug creation and discovery. [COMPANY NAME] proprietary code should only ever exist on [COMPANY NAME] or client-owned servers.
Server Environment:
Standards for Application Development – by @snipeyhead
If the application requires specific server environment settings or modules (in php.ini, Apache, etc), these should be identified and outlined at the beginning of the project. Considerations for caching and/or compression should be taken into account at the development level and discussed at the server level.
Frameworks:
If a framework is to be used, Zend Framework, Symfony or CakePHP are the preferred PHP frameworks for [COMPANY NAME].
Version Control/Change Management:
Code revisions should be checked into a [COMPANY NAME] private Git repository. Developers must check in code at least once daily during a normal development cycle, and each check-in should contain a short but meaningful comment that references a bug, user story or technical task ticket number. More frequent check-ins are encouraged, and daily pushes to the central Git repo are required.
Databases:
A schema and ERD should be submitted prior to code development. If special my.cnf configuration options are required or recommended, these should be included with the ERD. If the database schema changes over the course of development, these changes should be disclosed along the way, and changes to the network or database structure should be documented and checked into version control.
Auditing:
Components of the application that perform actions that alter business-critical data should always have the action logged to an audit log. Destructive actions that are meant to delete businesscritical data should not be performed as a database deletion, but rather as an update to mark the record as deleted. This soft-delete should be logged in the audit log with a timestamp and the ID of the system user who performed the delete.
Contests:
Auditing and soft-deletes are especially critical for contest and promotions due to strict legal requirements. A plan for fraud-detection and entry auditing must be discussed with the client in advance to mitigate risk. Secure coding coupled with extensive logging and audit capabilities provide a solid foundation to detect fraudulent activities and bad actors.
Risk Assessment:
All major components of every application should include a risk assessment to determine the level of risk to business continuity if that component fails, a plan to recover from failure, and methods by which the individual component can be monitored so that if failure occurs, it is immediately identified.
Standards for Application Development – by @snipeyhead
These failure conditions should be tested prior to application launch, to confirm that the recovery process is viable. For example, in a situation where an application cache is implemented and is a critical component to an application, failure to write to or read from the cache should be tested, and the process in place to constantly monitor the integrity of the caching system should be tested.
Third Party Dependencies/Risk:
A matrix of third party dependencies should be created to outline any outside domains, networks, APIs, etc that are utilized for every application. This matrix should include the following: type of dependency (API, javascript, tracking pixel, etc) description of the function the third-party system performs impact on the application if the third-party system were to fail probability of failure by the third-party system steps that will be taken in the event of third-party system failure
Privacy:
Our goal must always be to collect the minimum amount of user data possible without compromising the application’s business function. If we are collecting personally identifiable data from users, every piece of information collected must have a direct business reason associated with it. Personal data is never collected “just in case we need it someday.” All applications must contain a privacy policy that discloses what data we collect, for what purpose we collect it, and how the user can opt out. Email addresses and other personal information must never be shared with any third party other than the client for which the application is being developed.
Minimum Security Requirements:
All developers are expected to understand and comply with the OWASP guidelines for secure application development. Data Filtering/Validation All user input should be validated by both client-side and server-side controls where applicable. Database requests should be tokenized using prepared statements to mitigate risk of SQL Injection attacks, and no data should be trusted to be inserted into a database, posted to an API, or displayed back to the user in any way until it has been fully filtered. When developing forms, a whitelist policy where only certain types of data input are accepted should be implemented where practical (as opposed to a blacklist policy, where only certain types of data are rejected.) In instances where a whitelist policy is not possible (textarea submissions in a CMS, For example), HTML, CSS and JavaScript code should be stripped or encoded before insertion into the database, and escaped on the way out.
Standards for Application Development – by @snipeyhead
CSRF Prevention Nonces or CAPTCHAS to prevent spamming and CSRF attacks must be utilized in any POST or GET request that sends email, modifies user data, or performs any other medium to high risk activity within the application. Password Security Applications that require a login should use bcrypt as the encryption method (where system performance would not be aversely affected) with salt. Passwords must never be stored in cleartext in the database. As such, passwords should never be emailed to the user in a lost-password scenario. A link enabling the user to reset their password should be provided. In cases with a failed login attempt, error messages should not disclose whether the username, the password or both have failed, but should instead utilize more generic “login failed” language to prevent disclosing partial user login information by way of error messages. Failed logins should be logged, and implement a lockout period after a predetermined number of tries. Login failures from a login attempt where partial information is incorrect should take the same amount of time (either naturally or artificially) as a login failure from a login attempt where no data submitted matches valid login data in the database to prevent timing attacks. Minimum password requirements should be implemented in all applications where the user is able to create their own password. Passwords should be a minimum of 8 characters, requiring at least one symbol, one number and one uppercase character. Secure Socket Layer Any transaction where personal user data (including user login, profile editing, password resets, etc) could potentially be transmitted or modified must be run over SSL with a minimum of 1024-bit encryption. Session Management User sessions must never contain personal data, or data that could be captured over an insecure connection and used in a replay attack. Database Encryption In cases where medium or higher level PII is collected and stored on the server, database encryption should be implemented to protect user data.
Standards for Application Development – by @snipeyhead
Last edited
By
Notes
Standards for Application Development – by @snipeyhead
Purpose:
This document outlines the minimum set of standards for environment, coding standards, security and privacy for all applications developed by [COMPANY NAME], or for [COMPANY NAME] through contractors.
Documentation:
Inline code documentation should be provided inline using phpDoc style commenting. http://www.phpdoc.org/ Additional documentation regarding special requirements or instructions for deployment should be included in a detailed README document and supplemental documentation.
Development/Staging:
Code should be written to intelligently detect whether the environment is development, staging or production based on IP or domain name. The domain names and IP addresses should be easily accessible in a configuration file. Detection code and virtual host configurations should fail to production to prevent accidental exposure of the development or staging environments. Development, staging and QA environments should be restricted by IP address and/or username+password authentication so that non-production environments are never exposed to the public. For Facebook pages and applications, development versions of pages should remain unpublished, and applications should remain sandboxed at all times. Applications and pages that will eventually be production versions should be unpublished/sandboxed until launch. Live data that includes real user PII should never be used in test, staging or QA environments. While it is critical to use realistic data in testing environments, actual personally identifiable information should be obfuscated or altered in such a way that it never reflects actual user data. (Example: rewrite all user telephone numbers to reflect randomized digits.) Penetration and vulnerability assessments will be performed at every development milestone, and developers should be load-testing throughout the course of development with realistic database data to quickly identify bugs that could cause issues under stress. Unit tests should be performed on every Git push to limit the amount of time between bug creation and discovery. [COMPANY NAME] proprietary code should only ever exist on [COMPANY NAME] or client-owned servers.
Server Environment:
Standards for Application Development – by @snipeyhead
If the application requires specific server environment settings or modules (in php.ini, Apache, etc), these should be identified and outlined at the beginning of the project. Considerations for caching and/or compression should be taken into account at the development level and discussed at the server level.
Frameworks:
If a framework is to be used, Zend Framework, Symfony or CakePHP are the preferred PHP frameworks for [COMPANY NAME].
Version Control/Change Management:
Code revisions should be checked into a [COMPANY NAME] private Git repository. Developers must check in code at least once daily during a normal development cycle, and each check-in should contain a short but meaningful comment that references a bug, user story or technical task ticket number. More frequent check-ins are encouraged, and daily pushes to the central Git repo are required.
Databases:
A schema and ERD should be submitted prior to code development. If special my.cnf configuration options are required or recommended, these should be included with the ERD. If the database schema changes over the course of development, these changes should be disclosed along the way, and changes to the network or database structure should be documented and checked into version control.
Auditing:
Components of the application that perform actions that alter business-critical data should always have the action logged to an audit log. Destructive actions that are meant to delete businesscritical data should not be performed as a database deletion, but rather as an update to mark the record as deleted. This soft-delete should be logged in the audit log with a timestamp and the ID of the system user who performed the delete.
Contests:
Auditing and soft-deletes are especially critical for contest and promotions due to strict legal requirements. A plan for fraud-detection and entry auditing must be discussed with the client in advance to mitigate risk. Secure coding coupled with extensive logging and audit capabilities provide a solid foundation to detect fraudulent activities and bad actors.
Risk Assessment:
All major components of every application should include a risk assessment to determine the level of risk to business continuity if that component fails, a plan to recover from failure, and methods by which the individual component can be monitored so that if failure occurs, it is immediately identified.
Standards for Application Development – by @snipeyhead
These failure conditions should be tested prior to application launch, to confirm that the recovery process is viable. For example, in a situation where an application cache is implemented and is a critical component to an application, failure to write to or read from the cache should be tested, and the process in place to constantly monitor the integrity of the caching system should be tested.
Third Party Dependencies/Risk:
A matrix of third party dependencies should be created to outline any outside domains, networks, APIs, etc that are utilized for every application. This matrix should include the following: type of dependency (API, javascript, tracking pixel, etc) description of the function the third-party system performs impact on the application if the third-party system were to fail probability of failure by the third-party system steps that will be taken in the event of third-party system failure
Privacy:
Our goal must always be to collect the minimum amount of user data possible without compromising the application’s business function. If we are collecting personally identifiable data from users, every piece of information collected must have a direct business reason associated with it. Personal data is never collected “just in case we need it someday.” All applications must contain a privacy policy that discloses what data we collect, for what purpose we collect it, and how the user can opt out. Email addresses and other personal information must never be shared with any third party other than the client for which the application is being developed.
Minimum Security Requirements:
All developers are expected to understand and comply with the OWASP guidelines for secure application development. Data Filtering/Validation All user input should be validated by both client-side and server-side controls where applicable. Database requests should be tokenized using prepared statements to mitigate risk of SQL Injection attacks, and no data should be trusted to be inserted into a database, posted to an API, or displayed back to the user in any way until it has been fully filtered. When developing forms, a whitelist policy where only certain types of data input are accepted should be implemented where practical (as opposed to a blacklist policy, where only certain types of data are rejected.) In instances where a whitelist policy is not possible (textarea submissions in a CMS, For example), HTML, CSS and JavaScript code should be stripped or encoded before insertion into the database, and escaped on the way out.
Standards for Application Development – by @snipeyhead
CSRF Prevention Nonces or CAPTCHAS to prevent spamming and CSRF attacks must be utilized in any POST or GET request that sends email, modifies user data, or performs any other medium to high risk activity within the application. Password Security Applications that require a login should use bcrypt as the encryption method (where system performance would not be aversely affected) with salt. Passwords must never be stored in cleartext in the database. As such, passwords should never be emailed to the user in a lost-password scenario. A link enabling the user to reset their password should be provided. In cases with a failed login attempt, error messages should not disclose whether the username, the password or both have failed, but should instead utilize more generic “login failed” language to prevent disclosing partial user login information by way of error messages. Failed logins should be logged, and implement a lockout period after a predetermined number of tries. Login failures from a login attempt where partial information is incorrect should take the same amount of time (either naturally or artificially) as a login failure from a login attempt where no data submitted matches valid login data in the database to prevent timing attacks. Minimum password requirements should be implemented in all applications where the user is able to create their own password. Passwords should be a minimum of 8 characters, requiring at least one symbol, one number and one uppercase character. Secure Socket Layer Any transaction where personal user data (including user login, profile editing, password resets, etc) could potentially be transmitted or modified must be run over SSL with a minimum of 1024-bit encryption. Session Management User sessions must never contain personal data, or data that could be captured over an insecure connection and used in a replay attack. Database Encryption In cases where medium or higher level PII is collected and stored on the server, database encryption should be implemented to protect user data.
Standards for Application Development – by @snipeyhead
