Web Application Security Checklist V1

Category Name Description

Ensure that the web server does not support the ability to manipulate
HTTP Methods
resources from the Internet (e.g., PUT and DELETE).
Implement HTTP Strict Transport Security (HSTS) HTTP header in the web
HTTP Strict Transport Security server to ensure all communication from a browser is sent over HTTPS (HTTP
Secure) and prevent man-in-the-middle attacks.
Implement X-XSS-Protection HTTP header in the web server to prevent XSS
HTTP X-XSS-Protection
(Cross-Site Scripting).

Configuration The X-Frame-Options HTTP response header can be used to indicate whether
or not a browser should be allowed to render a page in a <frame>, <iframe>,
and Deploy X-Frame-Options Header
<embed>, or <object>. Use the X-Frame-Options header to
Management prevent Clickjacking vulnerability.
Mark all of the important cookies as HTTP Only in the web server. Using the
HttpOnly Flag HttpOnly flag when generating a cookie helps mitigate the risk of client-side
script accessing the protected cookie.
Known Vulnerabilities / Security Patches Ensure that known vulnerabilities that vendors have patched are not present.
Ensure that no back-up files of source code are accessible on the publicly
Back-up Files
accessible part of the application.
Ensure that common configuration issues such as directory listings have been
Web Server Configuration
addressed.
Ensure that administrative interfaces to infrastructure, such as web servers
Infrastructure Admin Interfaces
and application servers, are not accessible to the Internet.
Ensure that administrative interfaces to the applications are not accessible
Application Admin Interfaces
to the Internet.
Data Protection Transport - TLS Version Ensure to use the latest TLS version.

Source: https://github.com/MohammedAljuhani/Web-Application-Security-Checklist
1
 Web Application Security Checklist V1
Category Name Description
Ensure that resources that require authorization perform adequate
Authorization
authorization checks before being sent to a user.
Specify a minimum password length of at least eight characters. Longer
passwords provide more protection against brute force attacks. Complex
Authentication
passwords are requiring mixed character sets (alpha, numeric, special, mixed
case).
Use a CAPTCHA on any web Forms (e.g., Login page and Registration page) to
CAPTCHA
prevent automated attacks.
The most obvious way to block brute-force attacks is to lock out accounts
after a defined number of incorrect password attempts. Account lockouts
Account Lockouts After Failed Attempts
can last a specific duration, such as one hour, or the accounts could remain
locked until manually unlocked by an administrator.
Access Control Implement 2-Factor Authentication (2FA) on critical functions such as login
2-Factor Authentication (2FA)
and admin page to reinforce authentication/authorization.
Ensure that once a valid user has logged in, it is not possible to change the
Authorization Parameter Manipulation
session ID’s parameter to reflect another user account.
Session timeout management and expiration must be enforced server-side:
• Set session timeout to the minimal value possible depending on the
context of the application.
• Avoid the “infinite” session timeout.
Session Timeout Management • Prefer the declarative definition of the session timeout in order to apply
global timeout for all application sessions.
• The application has to track the inactivity time server-side and, after the
timeout is expired, automatically invalidate the current user’s session and
delete every data stored on the client.

Source: https://github.com/MohammedAljuhani/Web-Application-Security-Checklist
2
 Web Application Security Checklist V1
Category Name Description
Default accounts are often the source of unauthorized access by a malicious
Change Default Account Passwords user. When possible, they should be changed immediately upon installation
and configuration of the system or application.
Ensure data is protected to ensure its confidentiality and integrity, where
Data Storage
required.
Data Protection Passwords Passwords must be hashed before getting stored in the database.
Sensitive Data in HTML Ensure that there is no sensitive data in the HTML
Sanitize and filter user inputs to prevent web attacks such as SQL injection
Input Injection
and XSS (Cross-Site Scripting).
CSRF is an attack vector that tricks a web browser into executing an
unwanted action in an application to which a user is logged in.
Input Validation Cross-Site Request Forgery (CSRF) Protection
Check if your framework has built-in CSRF protection, and use it.
If the framework does not have built-in CSRF protection, add CSRF tokens to
all state-changing requests (requests that cause actions on the site) and
validate them on the backend.
Encoding Encode all input data before sending the response to the browser
Ensure that the application does not present application error messages to
Error Handling Application Error Messages
an attacker that could be used in an attack.

Source: https://github.com/MohammedAljuhani/Web-Application-Security-Checklist
3
 References
• https://owasp.org/www-project-web-security-testing-guide/assets/archive/OWASP_Web_Application_Penetration_Checklist_v1_1.pdf
• https://www.process.st/checklist/application-security-audit-checklist-template/
• https://github.com/0xRadi/OWASP-Web-Checklist

Source: https://github.com/MohammedAljuhani/Web-Application-Security-Checklist
4