Standards For Application Development
Standards For Application Development
Last edited
By
Notes
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:
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].
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.
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.
Privacy:
Our goal must always be to collect the minimum amount of user data possible without compromising the applications 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.
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.