Secure Coding Checklist

System Name:

Submitted By: Date of Submission:

Reviewed By: Approved By:

System Status: Accepted/ Refused/Need to be Modified

Date of Acceptance:
Input Validation
Conduct all data validation on a trusted system (e.g., The server)
Identify all data sources and classify them into trusted and untrusted. Validate all data
from untrusted sources (e.g., Databases, file streams, etc.)
All validation failures should result in input rejection
Validate all client provided data before processing, including all parameters, URLs and
HTTP header content (e.g., Cookie names and values). Be sure to include automated post
backs from JavaScript, Flash or other embedded code
Verify that header values in both requests and responses contain only ASCII characters
Validate data from redirects (An attacker may submit malicious content directly to the
target of the redirect, thus circumventing application logic and any validation performed
before the redirect)
Validate for expected data types
Validate data range
Validate data length
Output Encoding
Conduct all encoding on a trusted system (e.g., The server)
Contextually output encode all data returned to the client that originated outside the
application's trust boundary. HTML entity encoding is one example, but does not work in
all cases
Encode all characters unless they are known to be safe for the intended interpreter
Contextually sanitize all output of un-trusted data to queries for SQL, XML, and LDAP
Sanitize all output of un-trusted data to operating system commands
Authentication and Password Management
Require authentication for all pages and resources, except those specifically intended to
be public
All authentication controls must be enforced on a trusted system (e.g., The server)
Establish and utilize standard, tested, authentication services whenever possible
Use a centralized implementation for all authentication controls, including libraries that
call external authentication services
Segregate authentication logic from the resource being requested and use redirection to
and from the centralized authentication control
Validate the authentication data only on completion of all data input, especially for
sequential authentication implementations

1
 Secure Coding Checklist

Authentication credentials for accessing services external to the application should be

encrypted and stored in a protected location on a trusted system (e.g., The server). The
source code is NOT a secure location
Enforce password complexity requirements established by policy or regulation.
Authentication credentials should be sufficient to withstand attacks that are typical of the
threats in the deployed environment. (e.g., requiring the use of alphabetic as well as
numeric and/or special characters)
Notify users when a password reset occurs
Prevent password re-use
The last use (successful or unsuccessful) of a user account should be reported to the user
at their next successful login
Use Multi-Factor Authentication for highly sensitive or high value transactional accounts
Access Control
Use only trusted system objects, e.g., server-side session objects, for making access
authorization decisions
Restrict access to files or other resources, including those outside the application's direct
control, to only authorized users
Restrict access to protected URLs to only authorized users
Restrict access to protected functions to only authorized users
Restrict direct object references to only authorized users
Restrict access to services to only authorized users
Restrict access to application data to only authorized users
Restrict access to user and data attributes and policy information used by access controls
Restrict access security-relevant configuration information to only authorized users
Create an Access Control Policy to document an application's business rules, data types
and access authorization criteria and/or processes so that access can be properly
provisioned and controlled. This includes identifying access requirements for both the
data and system resources
Cryptographic Practices
All cryptographic functions used to protect secrets from the application user must be
implemented on a trusted system (e.g., The server)
Protect master secrets from unauthorized access
Error Handling and Logging
The application should handle application errors and not rely on the server configuration
Error handling logic associated with security controls should deny access by default
All logging controls should be implemented on a trusted system (e.g., The server)
Logging controls should support both success and failure of specified security events
Restrict access to logs to only authorized individuals
Log all input validation failures
Log all authentication attempts, especially failures
Log all access control failures
Log all administrative functions, including changes to the security configuration settings

2
 Secure Coding Checklist

Data Protection
Implement least privilege, restrict users to only the functionality, data and system
information that is required to perform their tasks
Protect all cached or temporary copies of sensitive data stored on the server from
unauthorized access and purge those temporary working files a soon as they are no
longer required.
Encrypt highly sensitive stored information, like authentication verification data, even on
the server side. Always use well vetted algorithms.
Do not store passwords, connection strings or other sensitive information in clear text or
in any noncryptographically secure manner on the client side. This includes embedding in
insecure formats like: MS view state, Adobe flash or compiled code
Do not include sensitive information in HTTP GET request parameters
Communication Security
Implement encryption for the transmission of all sensitive information. This should
include TLS for protecting the connection and may be supplemented by discrete
encryption of sensitive files or non-HTTP based connections
TLS certificates should be valid and have the correct domain name, not be expired, and be
installed with intermediate certificates when required
Utilize TLS connections for all content requiring authenticated access and for all other
sensitive information
Utilize TLS for connections to external systems that involve sensitive information or
functions
Database Configuration
Use strongly typed parameterized queries
The application should use the lowest possible level of privilege when accessing the
database
Use secure credentials for database access
Remove or change all default database administrative passwords. Utilize strong
passwords/phrases or implement multi-factor authentication
Disable any default accounts that are not required to support business requirements
The application should connect to the database with different credentials for every trust
distinction (e.g., user, read-only user, guest, administrators)
Timescales and Expected Outcomes
Has a cutover plan for the new or changed system been created?

Has the warranty/early life support period for the system been agreed?

Have the expected outcomes of the new or changed system been fully defined?

Are the expected outcomes measurable?

3
 Secure Coding Checklist

Processes, Measures, Methods and Tools

Are all new/changed processes, measures, methods and tools that will be used in
connection with the new or changed system in place in the following areas?
Availability Management (including backups and service continuity)

Capacity Management

Information Security Management

Configuration Management

Release and Deployment Management

Incident and Service Request Management

Problem Management

Financial Management

Business Relationship Management

Supplier Management

Technology Changes
Have any technology changes (hardware, software, network etc.) included in the new or
changed system been highlighted?
Is each technology component under maintenance?

Service Levels
Are service levels for the system defined and agreed?

Are the service level targets achievable?

Has the risk of service levels not being met been assessed and mitigated?

Are processes in place to record and report upon service levels?

Are they documented in an SLA?

Has the service catalogue been updated?

Contracts and Licensing

Are all required contracts with third parties agreed and signed?

Have copies of any contracts been filed in the correct location?

Have all required licenses been purchased?

Communication

4
 Secure Coding Checklist

Have all relevant parties been consulted/informed about the planned transition?

Have the main contacts for the operational system been defined?

Is there a plan for communication to the relevant parties?