Experienced Programmer Security Checklist
An online version of our cheat sheet , where you can check that your project meets basic safety principles and requirements. We are currently working on expanding it to include more topics - if you want to know when the update is online, follow our social media.
Selection of software (program, library, application)
Are you using the right software for development? It should be simple, reliable, efficient (fast and low RAM usage), have regular updates and not require additional programs to run. How do you identify it?
It’s contained in installations of distributions such as CentOS, Fedora, Debian, etc. Many people use such packages and their security is checked by other developers - experts.
It has a website with bug reporting and an archive of downloads of older versions.
Its EOL version with long-term support is available.
It has active development and several developers. You can check it, for example, based on last commits.
It doesn’t have too many open bugs without a solution.
It’s open source or has an open license. In this way, it’s less likely that the company will abruptly cancel it. With a closed source application, it may happen that no new developer is found to continue its maintenance, and thus the app disappears.
It doesn’t have dependencies. It operates independently, without the need to install additional programs for its operation. If these dependencies exist, don’t install them via pip/npm, but rather request the installation from the distribution. Beware, every manually installed library should be regularly updated and monitored for any additional dependencies.
Credentials, data, authentication
Database
Check the functioning of backup. Set as low an interval as possible, you never know when something will go wrong literally from minute to minute. And also try to see if you can restore the backup without any problems. It will be useless if you can’t put it back on.
Is your project compliant with the current GDPR? To be sure, check out the current privacy law (it changes) and adjust what needs to be done now. It’ll help you avoid a fat fine.
What about user passwords? Are they hashed? Use, for example, the secure bcrypt algorithm.
Do you store sensitive data in full (e-mails, addresses, etc.) somewhere, for example because of a newsletter? If you really need them, create a list of all places where they are located (a mailchimp database, an office document, a file in the second drawer). This is useful for both attacks and official checks.
Prevent SQL-injection. Check the use of the correct commands. For example, if you use NPM, don’t put npm-mysql there, but deploy npm-mysql2, which supports "prepared statements".
Applications
Do not use innerHTML - if you want to edit HTML content, use textContent, innerText, or setHTML() instead.
If it’s important for you to display the content as HTML code, verify the input properly before you edit the DOM , for example, using the DOMPurify open source library and its sanitize() function.
If you have React deployed, avoid rash use of property dangerouslySetInnerHtml.
Encode user-controlled data to prevent execution of malicious HTML codes by a parser when viewed in the app. If you use one of the more advanced frameworks like React, you’ve partially won - they already have automatic escaping and encryption.
Don’t forget protection against bots and equip all forms with reCaptcha.
Before sending user inputs to the server, clear the data of potential malicious parts of the code (it’s also protection against, for example, SQL Injection). The easiest way to do this is again with DOMPurify.sanitize().
Check your error messages, too. On the production, throw away details that hackers can exploit, and turn off the debug as well. Instead, set up a detailed log entry for proper diagnostics. However, you may want to leave personal user information out of it.
Have the right cookies. If they contain sensitive data, they must be set as httpOnly.
Set a strict Content Security Policy (CSP). Never trust everything the server sends - set up a CSP header and strictly control the sources your app can load.
Protect in the header. Use the X-XSS-Protection header in the clients’ responses, or cover it with a strictly defined CSP with the prohibition of using inline JavaScript. Also, don’t forget to use CSRF tokens.
Don’t use GET with sensitive data or tokens in the URL because they are logged on to the server and proxy.
Define which external files can be loaded to the page and from where. If you don’t have a tool for it, use the standard rules from the "same-origin policy".
APIs
Cloud and Server
Tips at the end
Resources
