A new dynamic revenue generating website is popping in the internet every 1 min. Do you web application security checklist know how many lines of code written in a day? Over 500 million lines of code! Yes, True. Millions of lines of web application code is written everyday across the globe.
How securely is your team coding then? This is the most important thing. Does your team know the web application security checklist best simple practices to follow to make your web app secured? Here is a checklist that can help your team build robust and secure applications.
Subscribe to our mailing list to understand more about the best practices.
- Sanitize the inputs at the client side as well at the server side. You should not allow special characters, null characters and funny scripts. This step should prevent the attackers from XSS and various Injections like SQL etc.
- You can’t just sanitize client side and think that you are secured. Anyone could always turn off JavaScript or change the values and submit them to your server.
- Use Strict Contextual Escaping (SCE), Most Javascripts these days help you with this escaping. This helps in avoiding major XSS and SQL attacks.
- Always Encode the request/responses. Especially, the response that is sent from the server to the client should be encoded, so that the browser does not execute it if it’s a payload. This will prevent XSS and other scripting based attacks.
- Always use HTTPS for all domain entries. The domain entry at the url should be considered and redirected properly i.e., the user might try in any of the following fashions:Entering the url in any of the above mentioned ways should be redirected to the https://www.example.com
- http://www.example.com
- example.com
- http://example.com
- http://10.43.14.123
- Do not use obsolete encryption and hashing algorithms like MD4, MD5, SHA1, DES.
- Configure the web server to disallow directory listing.
- Do not store sensitive data like usernames and passwords inside cookies. Never use default names for sessions like PHPSESSID, ASP.NET_SessionId etc but instead use custom names.
- Check the randomness of the session and make sure the session gets expired after logout and on idle usage. The expired sessions should no longer be useful for future client to server transactions.
- Always set secure and HttpOnly flags in cookies.
- Use TLS. Do not use SSL. Simply disable SSL in server and always use TLS 1.2 for certificates.
- Always set a strong password policy and also implement security measures like captcha to mitigate from brute force attacks. The randomness with which you generate default password and user related content should be absolutely random.
- Form’s hidden fields should not contain sensitive information. Make sure no sensitive information is collected through hidden fields.
- File upload functionality should be properly verified, not only at the client side but also at the server side because the client side verification alone is not sufficient. The attacker can intercept the traffic and change the file type or content. Verify the file extensions and file size properly. Do not accept any password protected zips/pdfs. Put a captcha in every file upload page.
- Use the following response headers on every response:
- strict-transport-security: max-age=7776000
- x-content-type-options: nosniff
- x-frame-options: SAMEORIGIN
- x-xss-protection: 1; mode=block
- Make sure that any third party libraries or plugins that are used inside the application are free from any noted vulnerabilities. For information on existing CVE’s visit https://cve.mitre.org/.
- Displaying web server information in response headers is not recommended.
“Need a certified white hat hacker to assess your web app security? contact us here.”