Store Donate Join
PROJECTS CHAPTERS Member Store
Watch 16 Star
EVENTS ABOUT Login Donate Join 52
OWASP Secure Coding Practices - Quick Reference
Guide The OWASP®
Foundation works to
Secure Coding Practices improve the security of
software through its
community-led open
Home > Stable-en > 02-checklist
source software projects,
hundreds of chapters
Secure Coding Practices worldwide, tens of
Checklist thousands of members,
and by hosting local and
Input validation global conferences.
Conduct all input validation on a trusted
system (server side not client side) Secure Coding
Identify all data sources and classify them into Practice Quick-
trusted and untrusted
reference
Validate all data from untrusted sources
(databases, file streams, etc)
Guide
Use a centralized input validation routine for 1. Introduction
2. Checklist
the whole application
2.1 Input validation
Specify character sets, such as UTF-8, for all 2.2 Output encoding
input sources (canonicalization) 2.3 Authentication and
password management
Encode input to a common character set
2.4 Session management
before validating
2.5 Access control
All validation failures should result in input 2.6 Cryptographic practices
rejection 2.7 Error handling and
logging
If the system supports UTF-8 extended
2.8 Data protection
character sets and validate after UTF-8 2.9 Communication
decoding is completed security
2.10 System configuration
Validate all client provided data before 2.11 Database security
processing 2.12 File management
2.13 Memory management
Verify that protocol header values in both
2.14 General coding
requests and responses contain only ASCII practices
characters Appendix A. Overview
Validate data from redirects Appendix B. Glossary
Appendix C. External
Validate for expected data types using an references
"allow" list rather than a "deny" list
Validate data range
Upcoming OWASP
Validate data length
Global Events
If any potentially hazardous input must be
allowed then implement additional controls OWASP Global AppSec
Lisbon 2024
If the standard validation routine cannot
June 24-28, 2024
address some inputs then use extra discrete
checks OWASP Global AppSec
San Francisco 2024
Utilize canonicalization to address obfuscation
attacks September 23-27,
2024
Output encoding OWASP Global AppSec
Washington DC 2025
Conduct all output encoding on a trusted
November 3-7, 2025
system (server side not client side)
OWASP Global AppSec
Utilize a standard, tested routine for each type
San Francisco 2026
of outbound encoding
November 2-6, 2026
Specify character sets, such as UTF-8, for all
outputs
Contextually output encode all data returned to
the client from untrusted sources
Ensure the output encoding is safe for all
target systems
Contextually sanitize all output of un-trusted
data to queries for SQL, XML, and LDAP
Sanitize all output of untrusted 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
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
All authentication controls should fail securely
All administrative and account management
functions must be at least as secure as the
primary authentication mechanism
If your application manages a credential store,
use cryptographically strong one-way salted
hashes
Password hashing must be implemented on a
trusted system server side not client side)
Validate the authentication data only on
completion of all data input
Authentication failure responses should not
indicate which part of the authentication data
was incorrect
Utilize authentication for connections to
external systems that involve sensitive
information or functions
Authentication credentials for accessing
services external to the application should be
stored in a secure store
Use only HTTP POST requests to transmit
authentication credentials
Only send non-temporary passwords over an
encrypted connection or as encrypted data
Enforce password complexity requirements
established by policy or regulation
Enforce password length requirements
established by policy or regulation
Password entry should be obscured on the
user's screen
Enforce account disabling after an established
number of invalid login attempts
Password reset and changing operations
require the same level of controls as account
creation and authentication
Password reset questions should support
sufficiently random answers
If using email based resets, only send email to
a pre-registered address with a temporary
link/password
Temporary passwords and links should have a
short expiration time
Enforce the changing of temporary passwords
on the next use
Notify users when a password reset occurs
Prevent password re-use
Passwords should be at least one day old
before they can be changed, to prevent attacks
on password re-use
Enforce password changes based on
requirements established in policy or regulation,
with the time between resets administratively
controlled
Disable "remember me" functionality for
password fields
The last use (successful or unsuccessful) of a
user account should be reported to the user at
their next successful login
Implement monitoring to identify attacks
against multiple user accounts, utilizing the
same password
Change all vendor-supplied default passwords
and user IDs or disable the associated accounts
Re-authenticate users prior to performing
critical operations
Use Multi-Factor Authentication for highly
sensitive or high value transactional accounts
If using third party code for authentication,
inspect the code carefully to ensure it is not
affected by any malicious code
Session management
Use the server or framework’s session
management controls. The application should
recognize only these session identifiers as valid
Session identifier creation must always be
done on a trusted system (server side not client
side)
Session management controls should use well
vetted algorithms that ensure sufficiently random
session identifiers
Set the domain and path for cookies containing
authenticated session identifiers to an
appropriately restricted value for the site
Logout functionality should fully terminate the
associated session or connection
Logout functionality should be available from
all pages protected by authorization
Establish a session inactivity timeout that is as
short as possible, based on balancing risk and
business functional requirements
Disallow persistent logins and enforce periodic
session terminations, even when the session is
active
If a session was established before login, close
that session and establish a new session after a
successful login
Generate a new session identifier on any re-
authentication
Do not allow concurrent logins with the same
user ID
Do not expose session identifiers in URLs,
error messages or logs
Implement appropriate access controls to
protect server side session data from
unauthorized access from other users of the
server
Generate a new session identifier and
deactivate the old one periodically
Generate a new session identifier if the
connection security changes from HTTP to
HTTPS, as can occur during authentication
Consistently utilize HTTPS rather than
switching between HTTP to HTTPS
Supplement standard session management for
sensitive server-side operations, like account
management, by utilizing per-session strong
random tokens or parameters
Supplement standard session management for
highly sensitive or critical operations by utilizing
per-request, as opposed to per-session, strong
random tokens or parameters
Set the "secure" attribute for cookies
transmitted over an TLS connection
Set cookies with the HttpOnly attribute, unless
you specifically require client-side scripts within
your application to read or set a cookie's value
Access control
Use only trusted system objects, e.g. server
side session objects, for making access
authorization decisions
Use a single site-wide component to check
access authorization. This includes libraries that
call external authorization services
Access controls should fail securely
Deny all access if the application cannot
access its security configuration information
Enforce authorization controls on every
request, including those made by server side
scripts
Segregate privileged logic from other
application code
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
Server side implementation and presentation
layer representations of access control rules
must match
If state data must be stored on the client, use
encryption and integrity checking on the server
side to detect state tampering
Enforce application logic flows to comply with
business rules
Limit the number of transactions a single user
or device can perform in a given period of time,
low enough to deter automated attacks but
above the actual business requirement
Use the "referer" header as a supplemental
check only, it should never be the sole
authorization check as it is can be spoofed
If long authenticated sessions are allowed,
periodically re-validate a user’s authorization to
ensure that their privileges have not changed
and if they have, log the user out and force them
to re-authenticate
Implement account auditing and enforce the
disabling of unused accounts
The application must support disabling of
accounts and terminating sessions when
authorization ceases
Service accounts or accounts supporting
connections to or from external systems should
have the least privilege possible
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
Protect secrets from unauthorized access
Cryptographic modules should fail securely
All random numbers, random file names,
random GUIDs, and random strings should be
generated using the cryptographic module’s
approved random number generator
Cryptographic modules used by the application
should be compliant to FIPS 140-2 or an
equivalent standard
Establish and utilize a policy and process for
how cryptographic keys will be managed
Error handling and logging
Do not disclose sensitive information in error
responses, including system details, session
identifiers or account information
Use error handlers that do not display
debugging or stack trace information
Implement generic error messages and use
custom error pages
The application should handle application
errors and not rely on the server configuration
Properly free allocated memory when error
conditions occur
Error handling logic associated with security
controls should deny access by default
All logging controls should be implemented on
a trusted system
Logging controls should support both success
and failure of specified security events
Ensure logs contain important log event data
Ensure log entries that include un-trusted data
will not execute as code in the intended log
viewing interface or software
Restrict access to logs to only authorized
individuals
Utilize a central routine for all logging
operations
Do not store sensitive information in logs,
including unnecessary system details, session
identifiers or passwords
Ensure that a mechanism exists to conduct log
analysis
Log all input validation failures
Log all authentication attempts, especially
failures
Log all access control failures
Log all apparent tampering events, including
unexpected changes to state data
Log attempts to connect with invalid or expired
session tokens
Log all system exceptions
Log all administrative functions, including
changes to the security configuration settings
Log all backend TLS connection failures
Log cryptographic module failures
Use a cryptographic hash function to validate
log entry integrity
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,
such as authentication verification data, even if
on the server side
Protect server-side source-code from being
downloaded by a user
Do not store passwords, connection strings or
other sensitive information in clear text or in any
non-cryptographically secure manner on the
client side
Remove comments in user accessible
production code that may reveal backend
system or other sensitive information
Remove unnecessary application and system
documentation as this can reveal useful
information to attackers
Do not include sensitive information in HTTP
GET request parameters
Disable auto complete features on forms
expected to contain sensitive information,
including authentication
Disable client side caching on pages
containing sensitive information
The application should support the removal of
sensitive data when that data is no longer
required
Implement appropriate access controls for
sensitive data stored on the server. This includes
cached data, temporary files and data that
should be accessible only by specific system
users
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
Failed TLS connections should not fall back to
an insecure connection
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
Utilize a single standard TLS implementation
that is configured appropriately
Specify character encodings for all connections
Filter parameters containing sensitive
information from the HTTP referer, when linking
to external sites
System configuration
Ensure servers, frameworks and system
components are running the latest approved
version
Ensure servers, frameworks and system
components have all patches issued for the
version in use
Turn off directory listings
Restrict the web server, process and service
accounts to the least privileges possible
When exceptions occur, fail securely
Remove all unnecessary functionality and files
Remove test code or any functionality not
intended for production, prior to deployment
Prevent disclosure of your directory structure in
the robots.txt file by placing directories not
intended for public indexing into an isolated
parent directory
Define which HTTP methods, Get or Post, the
application will support and whether it will be
handled differently in different pages in the
application
Disable unnecessary HTTP methods
If the web server handles different versions of
HTTP ensure that they are configured in a
similar manner and ensure any differences are
understood
Remove unnecessary information from HTTP
response headers related to the OS, web-server
version and application frameworks
The security configuration store for the
application should be able to be output in human
readable form to support auditing
Implement an asset management system and
register system components and software in it
Isolate development environments from the
production network and provide access only to
authorized development and test groups
Implement a software change control system
to manage and record changes to the code both
in development and production
Database security
Use strongly typed parameterized queries
Utilize input validation and output encoding
and be sure to address meta characters. If these
fail, do not run the database command
Ensure that variables are strongly typed
The application should use the lowest possible
level of privilege when accessing the database
Use secure credentials for database access
Connection strings should not be hard coded
within the application. Connection strings should
be stored in a separate configuration file on a
trusted system and they should be encrypted.
Use stored procedures to abstract data access
and allow for the removal of permissions to the
base tables in the database
Close the connection as soon as possible
Remove or change all default database
administrative passwords
Turn off all unnecessary database functionality
Remove unnecessary default vendor content
(for example sample schemas)
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 (for example user, read-only user,
guest, administrators)
File management
Do not pass user supplied data directly to any
dynamic include function
Require authentication before allowing a file to
be uploaded
Limit the type of files that can be uploaded to
only those types that are needed for business
purposes
Validate uploaded files are the expected type
by checking file headers rather than by file
extension
Do not save files in the same web context as
the application
Prevent or restrict the uploading of any file that
may be interpreted by the web server.
Turn off execution privileges on file upload
directories
Implement safe uploading in UNIX by mounting
the targeted file directory as a logical drive using
the associated path or the chrooted environment
When referencing existing files, use an allow-
list of allowed file names and types
Do not pass user supplied data into a dynamic
redirect
Do not pass directory or file paths, use index
values mapped to pre-defined list of paths
Never send the absolute file path to the client
Ensure application files and resources are
read-only
Scan user uploaded files for viruses and
malware
Memory management
Utilize input and output controls for untrusted
data
Check that the buffer is as large as specified
When using functions that accept a number of
bytes ensure that NULL terminatation is handled
correctly
Check buffer boundaries if calling the function
in a loop and protect against overflow
Truncate all input strings to a reasonable
length before passing them to other functions
Specifically close resources, don’t rely on
garbage collection
Use non-executable stacks when available
Avoid the use of known vulnerable functions
Properly free allocated memory upon the
completion of functions and at all exit points
Overwrite any sensitive information stored in
allocated memory at all exit points from the
function
General coding practices
Use tested and approved managed code
rather than creating new unmanaged code for
common tasks
Utilize task specific built-in APIs to conduct
operating system tasks. Do not allow the
application to issue commands directly to the
Operating System, especially through the use of
application initiated command shells
Use checksums or hashes to verify the
integrity of interpreted code, libraries,
executables, and configuration files
Utilize locking to prevent multiple simultaneous
requests or use a synchronization mechanism to
prevent race conditions
Protect shared variables and resources from
inappropriate concurrent access
Explicitly initialize all your variables and other
data stores, either during declaration or just
before the first usage
In cases where the application must run with
elevated privileges, raise privileges as late as
possible, and drop them as soon as possible
Avoid calculation errors by understanding your
programming language's underlying
representation
Do not pass user supplied data to any dynamic
execution function
Restrict users from generating new code or
altering existing code
Review all secondary applications, third party
code and libraries to determine business
necessity and validate safe functionality
Implement safe updating using encrypted
channels
\newpage
Edit on GitHub
Spotlight: Approach Cyber
Approach Cyber is a pure-play cyber security and privacy company. At Approach, we believe
that everyone deserves digital peace-of-mind. This is our vision, our aspiration for a society
where each and every one is reassured, where there is confidence and security in the digital
world. Therefore, our role is to bring cyber serenity to society. Every day, we take care of your
cybersecurity while you focus on your business. We help you to prevent, withstand and
recover from cyber security incidents and enable you to keep full attention on your core
activities.
Corporate Supporters
Become a corporate supporter
HOME PROJECTS CHAPTERS EVENTS ABOUT
PRIVACY SITEMAP CONTACT
OWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec
California, AppSec Cali, SnowFROC, and LASCON are trademarks of the OWASP Foundation, Inc. Unless
otherwise specified, all content on the site is Creative Commons Attribution-ShareAlike v4.0 and provided
without warranty of service or accuracy. For more information, please refer to our General Disclaimer.
OWASP does not endorse or recommend commercial products or services, allowing our community to
remain vendor neutral with the collective wisdom of the best minds in software security worldwide. Copyright
2023, OWASP Foundation, Inc.
