Top 5 Bad Application Security Practices

bad security practices

We all come across good security practices and make ourselves familiar with them to develop secured code. However, it may also be good idea at times to know about some of the bad security practices such that we, for sure, try and avoid them.



Following are top 5 bad practices you may want to know about:

  1. Do NOT interact with un-trusted programs: Make sure that the external programs that your program is invoking for reasons such as data or functionality, must have got reviewed and tested for security compliance. One of the common entry points into secured applications are these unsecured applications and hackers just love them. Hackers, when planning the attack vector try and analyze all the entry points of the application and assess the security of the external applications and, attack them to hack another systems. Thus, if at all, you need your applications to talk to external external applications, make sure that those applications are well reviewed and tested for security (penetration testing).
  2. Do NOT trust on any external information: In fact, consider all external information as malicious. Never believe on any data entering into system even when  you are creating an admin module or for that matter any application which  are created for internal usage and would never be used by external users. This is primarily that internal users may unintentionally send the malicious data, may be due to malicious software on his system, thereby hacking the system.
  3. Do NOT display Exception Stacktrace: Many a times, applications fail in unexpected fashion (degrade ungracefully) thereby exposing critical system information via stack-trace etc. Thus, one must take enough care to fail to a safe state such as forcing users to login page etc, OR, display enough message in exception for users to understand the exception without displaying stacktrace related information.
  4. Do NOT rely on any third party component used in your system: In real world scenario, it is but obvious that we may end up using external libraries in our applications to access different business related functionality. Given that fact, it becomes very important to do security testing of external libraries and make sure that they pass the security criteria. Most of the times, you get to read the security flaws in those libraries on the internet. Make sure that there are no critical security flaws in the dependent libraries to be used into your system. This is also included as one of top OWASP security vulnerability in the year 2013 which is termed as “Using Components with Known Vulnerabilities“.
  5. Do NOT issue sensitive information by email: The sensitive information includes information such as passwords or business specific information such as credit card details. Generally, emails are forwarded and thus, there is a danger that the sensitive information stored in the email can end up getting shared with unwanted personnel which can lead to hacking of the system.


Ajitesh Kumar

Ajitesh Kumar

I have been recently working in the area of Data analytics including Data Science and Machine Learning / Deep Learning. I am also passionate about different technologies including programming languages such as Java/JEE, Javascript, Python, R, Julia, etc, and technologies such as Blockchain, mobile computing, cloud-native technologies, application security, cloud computing platforms, big data, etc. I would love to connect with you on Linkedin. Check out my latest book titled as First Principles Thinking: Building winning products using first principles thinking.
Posted in Application Security, Code Review. Tagged with , .

Leave a Reply

Your email address will not be published. Required fields are marked *