Website Pre Go-Live Checklist

11.02.20 01:10 PM Comment(s)

Website Pre Go-Live Checklist

  • HTTPS configured ?

    Https configuration is mandatory these days. It prevents data from being manipulated or intercepted. Google also gives preference in SEO for https sites. There are many vendors which provide SSL certs at cost and few vendors for free. LetsEncrypt is one which has a good reputation among free vendors.

  • HSTS - http header set ?

    Installing a Strict-Transport-Security header, it would be extremely difficult for attackers to steal data 

  • Ensure your content cannot be embedded in a frame on other websites 

    Cross-domain iframes can run malicious apps, trigger alerts, autoplay videos, and induce phishing. 

  • Ensure password entropy checks are carried out during sign-up 

This predicts the difficulty quotient of cracking a password by guess work, brute force, and dictionary attacks 

  • Store only hash of user passwords 

    Do not invent your own algorithm for repated hashing. Use PBKDF2, scrypt, or bcrypt 

  • Ban IP addresses after a certain number of unsuccessful attempts 

    For high risk sites, it is advisable to block an IP address after n number of unsuccessful attempts. Also, redirect the users to a message explaining the block, such as "malicious activity has been detected" 

  • What are you using to control ssh login attempts? 

    The most common suggestion is to turn off daemon service, which is sometimes a default installation. Use alternate authentication methods, instead of simple passwords. 

  • Ensure hash salts, database passwords, and server signing keys are not checked into source control 

    This would throttle data breaches. Salt hash is the basis of secure password storage. By putting the passwords in source control, anyine who has access to the repository can see your data. 

  • Unit tests to ensure one person cannot access another user's content 

    In a multi-tenant environment or role based access structure, authorization gets ignored and users via reverse engineering can get access to other user's data. 

  • Do forms set a cross-site request forgery cookie? 

    Cross-site request forgery attacks force an end-user to carry unwanted actions on a site they are authenticated in 

  • Do session cookies have the 'Secure' and 'HttpOnly' flag set? 

    Secure flags send the cookies only over HTTPS. HttpOnly flags prevents JavaScript from reading the cookies in case of XSS exploitation 

  • Is the server certificate 4096 bits or more? 

    Long-term future-proof key length is desired since the trouble of replacing signatures is pretty high 

  • Is TLS1.2 the only supported protocol? 

    Through this security protocol, a system can communicate with the involved party. The encrypted data would not be deciphered by intruders 

  • Supported symmetric ciphers use 256 bit keys or more 

    This bit size is the largest and it is unbreakable by brute force 

  • Deliver assets through a content delivery network 

    This ensures fast delivery of Internet content 

  • Validate form fields with restrictive regex 

    Regular expressions or regex help in defining a whitelist for input validation. Input validation is the first line line of defense during the creation of a secure app