This checklist is a helpful reference when performing a web application security test. It is not a complete list though - there are often application-specific vulnerabilities and subtle issues that this does not cover.
Authentication
Logging in with an invalid user name does not reveal whether the user exists
Accounts are locked after a number of failed logins
An attacker cannot reset the lockout (e.g. by removing cookies)
Can't easily lockout an account to cause a denial of service
After login a redirect is issued, to prevent refresh attacks
Both "change password" and "logout" functions are provided
User is informed of last login time
Change password requires provision of old password
Passwords are proactively checked for strength
Password is never revealed (e.g. in the source of change password)
Session Management
Session tokens are at least 128-bit
Session tokens are unpredictable
A new session is allocated at login (i.e. session fixation is prevented)
Logout invalidates the session token on the server
Cookie has "secure" and "httponly" options set and is non-persistent
Sessions have an inactivity timeout
Sessions have an absolute timeout
Injection Attacks
Cross-site scripting
HTTP response splitting
SQL injection
LIKE pattern injection
LDAP injection
XPATH injection
Mail header injection
Directory traversal
Null-byte injection
Shell script / batch injection
Server-side script injection (PHP, Perl, etc.)
XML injection
Try to bypass filters using over-long utf-8 encodings
Try to bypass filters using wide-ASCII, or other Unicode equivalents
Content Checks
No script or CSS tags reference resources on other servers
No script or CSS tags on a page that can be accessed over HTTPS use URLs beginning http://
Use of eval, document.write, innerHTML, etc. does not cause XSS
Comments in files do not reveal sensitive information
Frames/iframes, if used, have frame spoofing protection
autocomplete=off is set on all forms asking for personal information
Private IP addresses
Server Side Script Behaviour
Arbitrary redirection
Arbitrary message inclusion
File upload features restrict uploaded content to prevent compromise
JavaScript Hijacking
Scripts that cause write actions require POST with a CSRF token
Scripts that act as an open proxy or mail relay
Exponential format accepted
Server compromise by uploading XML that sources a stylesheet
Source code disclosure through scripts that allow read access to files
Authorisation
All protected resources check for a valid session
All protected resources check for user permissions (forced browsing)
Parameter tampering does not allow access to others' data
Page-to-page flow is correctly enforced where required
Form POST targets perform the same authorisation as form views
Miscellaneous
cache-control: private or stronger is used on sensitive pages
All client-side validation is repeated on the server
Site supports HTTPS, and sensitive pages forbid HTTP access
All pages are displayed with status and address bars
All URLs are expected from a customer's point of view
No "Mixture of secure and insecure content" warnings
Server Configuration
There are no "orphaned" files (exist on the web server, but not linked)
No backup versions of files are accessible (may reveal source code)
No common insecure scripts (e.g. snoop servlet) are accessible
Error messages do not provide overly-detailed information
Special Cases
Dynamic login questions: question cannot be changed by the user
Application forms: restarting a transaction doesn't leak information
Smoke & mirrors: generated emails are appropriately protected
Domain auth: domain accounts cannot be locked out from the Internet
Forgotten password: understand any information leaked or risks created
SSL Client Certificates
Does login check user name matches certificate?
Can you lock out an account without holding the certificate?
Is certificate required for every request?
Does it check the certificate matches the session ID?
Can you login using a self-signed certificate?
Are test/pre-prod certificates separated from live?
Nested Web Service
Is the WSDL file accessible?
Does access to the web service require a web session?
Does it check the web session user matches the WS user?
Also, most of this checklist also applies to the web service.
