The 10 Worst Cyber Security Mistakes Companies are Making—and How to Avoid Them

Jun 30, 2021
6 min read

Imagine you’re having a pleasant day at work - surfing the web, breezing your way through tasks & assignments.

Suddenly, a message pops up on your screen, “YOU’RE UNDER ATTACK!”

As dramatic as it sounds, that is not what a typical ‘cyber attack’ looks like.

A cyber attack is an attack carried out by cybercriminals on a single or numerous computers or networks utilizing one or more computers. A cyber attack can be used to maliciously destroy systems, steal data, or use a compromised computer as a launchpad for future attacks.

It may show up in the form of anything - an anonymous email containing a malicious link or an apparently harmless pop-up, siphoning off tremendous chunks of data from your computer once you click on it. Personal information like bank account details, passwords, credit card details, and could be retrieved by cybercriminals.

Here is a closer look at ten major mistakes that companies tend to overlook while designing their web pages/software and some preventive measures to avoid them.

#1 No Penetration Testing

Penetration tests are one of the most effective techniques to combat possible threats. This is a method of testing your software's security before an attacker has a chance to do so.

To do so, testers employ technologies that simulate hacking scenarios in order to detect and alter security flaws. Penetration testing allows your firm or development team to identify security vulnerabilities, compliance loopholes and replicate the real-world effects of a large-scale data breach.

  • Prevention: Provide information about in-scope targets to the penetration tester. Search for other information that was neglected, unknown, or not disclosed. Next, after finding a potential vulnerability,  carry out a ‘vulnerability assessment’ to obtain preliminary information and discover any potential security flaws that could allow an outside attacker to obtain access to the environment or technology under test. After evaluating the vulnerability assessment results, validate, attack, and exploit those vulnerabilities using manual methodologies, human intuition, and their backgrounds.

#2 Using Hardcoded Passwords Instead of Encrypted Passwords

Hardcoding passwords is a phrase that relates to placing non-encrypted (plain text) passwords and other confidential data (such as private keys) into source code. Although software engineers may not realize it, their source code is (or will be) frequently made public.

Hardcoded passwords are especially risky because they are easy targets for password guessing vulnerabilities, which allow hackers and malware to take control of firmware, devices (such as health monitoring equipment), systems, and software.

  • Prevention: In order to safeguard your company’s data, passwords should be encrypted. Encryption protects your company's data and information from potential risks, ensuring that even if an intruder gets access to your sensitive data, they'd be unlikely to be able to read any of it.

#3 Using Components with Known Vulnerabilities

Using code from a random user on GitHub or a forum may be convenient, but it comes with the danger of exposing yourself to a severe web security vulnerability.

It is always wise to do some investigation and possibly some auditing before introducing new code. Otherwise, an outside party might gain administrative access to your system, posing a severe cyber threat.

  • Prevention - Do not copy-paste code from unknown sources and be cautious while employing such components. Examine the code you're about to put into your software carefully, as a faulty code could damage the software beyond repair.

#4 No Third Party Code Testing

While developing software, one must always perform third-party code testing to ensure the full efficiency and effectiveness of the software as offered by the company.

On several occasions, proper testing is not done for third-party applications or codes which are integrated.

  • Prevention - To begin, it is critical to understand exactly what code is being used and for what purpose. Secondly, it is even more important to ensure that it has been tested and confirmed to be reliable before you introduce it to your software or system.

#5 Thinking It’s Just About Malware

Malware is still a crucial component of an attacker's early foothold. However, once inside, they frequently employ a variety of tactics to move laterally throughout your network. In many cases, this entails operating under the radar by harvesting sensitive data and detecting vulnerabilities using lawful administrator or ethical hacking techniques.

  • Prevention - Monitor and fend off other serious cyber threats like Phishing, Ransomware, Trojan horse, computer viruses, etc. Install reliable anti-virus software, avoid clicking on suspicious links or ‘offers’ which look too good to be true or download attachments from unknown sources. Back-up data regularly.

#6 Broken Authentication

This is a collection of issues that can arise as a result of faulty authentication, though not all these issues are derived from the same source.

> The URL might contain session ID and leak it to someone else via the referer header.

> Passwords may not be encrypted during storage or transmission.

> Because the session IDs are likely to be predictable, acquiring access is easier.

> Session fixation may be possible.

> Session hijacking, incorrectly configured timeouts, or HTTP (no SSL security) are all possibilities.

  • Prevention - Using a framework is the simplest way to avoid this web security risk. You might be able to do this correctly, but the former is far more straightforward. If you do decide to write your own code, be exceedingly cautious and educate yourself on the potential risks.

#7 Security Misconfiguration

Some common examples of security misconfiguration issues are:

> Running the application with debugging enabled in production.

> On the server, directory listing is enabled, which exposes sensitive information.

> Using outdated software (like WordPress plugins, old PhpMyAdmin).

> Default keys and passwords are not changed.

> Providing attackers with error handling information, such as stack traces.

  • Prevention - Have a good (ideally automated) “build and deploy” procedure in place that includes the ability to run tests during deployment. Post-commit hooks are a common answer to security misconfiguration, as they prevent code from being released with default passwords and/or with development code.

#8 Cross-site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is a type of attack that causes an authenticated user to do undesirable actions on a web application.

Since the web browser is misled into submitting a falsified request by a less privileged attacker, cross-site request forgery is a classic example of a confused deputy attack against a web browser.

  • Prevention - Keep a secret token in a hidden form field that the third-party site can't see. You should always double-check this secret field. When changing sensitive settings on some websites, you may be asked for your password as well (for example, password reminder email) although this is done mainly to prevent abandoned sessions (for example in an internet cafe).

#9 Insecure Direct Object References

This is a classic example of relying on user input and paying the price in the form of a security flaw. A direct object reference exposes an internal object to the user, such as a file or database key. The issue here is that the attacker can supply this reference and if authorization is not enforced (or is flawed), the attacker can gain access to or perform actions that they should not.

Let’s say, the code includes a download.php module that reads and allows users to download files by specifying the file name with a CGI parameter (e.g., download.php?file=something.txt). The developer removed authorization from the code, either by accident or out of laziness. The intruder will now use this to download any device files that the PHP user has access to, such as the application code or other documents. The attacker can now use this to download any device files that the PHP user has access to, such as the application code or any data left on the server, such as backups.

  • Prevention - Whitelist the options and perform user authorization correctly and consistently. The problem may usually be avoided by keeping data internally rather than relying on it being given from the client via CGI parameters. Most frameworks have session variables that are ideal for this.

#10 Unvalidated Redirects And Forwards

Assume the destination site has a redirect.php module with a GET parameter of a URL. By manipulating the parameter, a URL on can be created that directs the browser to When the user clicks the link, they will see, which they believe is safe to click.

They have no idea that this will redirect them to a malware drop (or any other harmful) page. Alternatively, the attacker may send the browser to and delete the profile.

It's worth noting that cramming unprocessed user-defined input into an HTTP header can result in header injection, which is a negative thing.

  • Prevention - Redirects should be avoided at all costs (they are seldom necessary). Have a list of valid locations to redirect to that are static. Whitelist the user-defined parameter, however difficult this may be.

It takes just five minutes - or less - for a hacker to access & change all of your company data, steal it or use it illegally if you are unaware.

That is why cybersecurity is more important than ever in this era of technology, especially in 2021.