8 Most Common Vulnerabilities For Web Security

Website vulnerablities

The OWASP or Open Web Security Project is a not – for-profit charity focused on improving software and web applications security. A list of top web security vulnerabilities is published by the organization based on data from various security organizations.

Web security vulnerabilities depend on software exploitation, detection and impact.

What is required to exploit the security vulnerability?

Highest exploit ability

if the attack only requires a web browser and advanced programming and tooling. Detectability–How easy is threat detection? The highest level is the URL, Form or Error message information and the lowest source code.

Impact or Damage–How much damage is caused if the vulnerability is exposed or attacked?

The highest comprehensive system crash and nothing at all. OWASP scanner online Top 10’s main objective is to educate developers, designers, managers, architects and organizations about the major security vulnerabilities. SQL Injection Cross Site Scripting Broken Authentication and Session Management Insecure Direct Object References Cross Site Request Forgery Misconfiguration Insecure Cryptographic Storage Failure to restrict URL Access Insufficient Transport Layer Protection Unvalidated redirects and forward SQL Injection. Get to know about free online sql injection scanner here.

10 Most Co vulnerabilities as per OWASP Top 10 are:

Too many companies wait until a security breach before web security best practices are a priority as an IT Security professional; I’ve seen how complex web development security issues can seem to many of my colleagues.

Effective web security strategies must be both proactive and defensive. This post is intended to spark a security mindset and hopefully, give the reader a healthy dose of paranoia.

This guide will focus on 10 web security pitfalls that you should be aware of and offer suggestions to avoid them. The Top 10 Web Vulnerabilities were identified by the Open Web Application Security Project (OWASP), an international non-profit organization whose mission is to improve software security around the world.

Get into the Cyber Security Career now!

Before we begin, a little bit of cyber security advice – authorization and authentication.

I am often confused about the difference between authorization and authentication when speaking with programmers and IT professionals. This confusion is exacerbated because the abbreviation auth can be used for both authorization and authentication. This is a common problem that should be addressed in the post as “Common Web Vulnerability Zero”.

Let’s first clarify the difference between these terms before we move on.

  • Authentication: A way to verify that a person is or appears to be a particular user. This can be done by verifying that they have correctly given their security credentials (passwords, answers to security questions, fingerprint scans, etc. ).
  • Authorization: A confirmation that a user has access or permission to perform a specific action.

Another way to put it authentication means knowing who an entity is, and authorization means knowing what an entity can do. Let’s now look at the top 10 issues in internet security.

Standard web security error #1: Injection flaws

Injection flaws are caused by a failure to filter untrusted data. This can occur when unfiltered data is passed to the SQL server (SQL Injection), to your browser (XSS – we’ll discuss this later), and to the LDAP Server (LDAP injection) or any other place. This is because attackers can inject commands into these entities, resulting in data loss and client browser hijacking.

Any information that you receive from untrusted sources should be filtered, preferably using an allowlist. A blocklist should be avoided as it is difficult and often easy to ignore. Blacklists that fail are often examples of antivirus software products. Pattern matching is not possible.

Prevention: Protecting against injection is as easy as filtering your input correctly and assessing whether it can be trusted. The bad news is that not all input can be trusted without being adequately filtered. However, this does not mean it should be.

For example, if you have 1,000 inputs, filtering only 999 is not enough. This leaves one area that could be the Achilles heel and bring down your system. You might think that inserting a SQL query result in another query is a good idea if the database is trusted. But if the perimeter of the query is not trusted, then the input is indirectly from malintent guys. This is Second Order SQL injection if you are interested.

Filtering is a difficult task (like cryptography), so I recommend that you rely on your framework’s filtering functions. They have been tested and thoroughly reviewed. Frameworks are not necessary for server security. You should seriously consider whether you don’t need them. It doesn’t 99 per cent of the time.

Standard web security error #2: Broken authentication

Broken authentication can lead to multiple problems, but not all are the same.

What do you think if anyone wanted to roll their authentication codes in 2014? ), I advise against it. It’s challenging to do it right, and there are many possible pitfalls to avoid, to name a few.

  1. The URL could contain the session ID and leak it to the referrer header.
  2. It is possible that the passwords are not encrypted in transit or storage.
  3. Access to the session IDs may be trivial because they are predictable.
  4. Session fixation may be possible.
  5. Session hijacking may be possible if timeouts are not correctly implemented or HTTP is used (no SSL security).

Prevention: The best way to prevent this web security vulnerability from happening is to use a framework. While you might be able to implement it correctly, the former is far more accessible. If you decide to roll your code, it is good to be very cautious and learn about the potential pitfalls. There are many.

Common Web Security Error #3: Cross-Site Scripting (XSS).

This is a standard input sanitization error (basically a case of common error #1). An attacker exposes your web application’s JavaScript tags. The user’s browser will execute the input if it is not cleaned up. You can create a link to persuade users to click it or do something more sinister. The script is executed upon page load and can be used, for instance, to send your cookies to the attacker.

Prevention, A simple web security solution does not return HTML tags to the client. This will protect against HTML injection. An attack in which an attacker injects plain HTML content into a client’s browser (such as images, flash players or loud invisible flash players) is a joint attack. While not very disruptive but certainly annoying (“please make it stop !”).”). Most often, you can convert all HTML entities to avoid this problem.

Common Web Security Error #4: Unsecure Direct Object References

This is the classic example of trusting user input but paying the price for a security vulnerability. Direct object references are when an internal object, such as a file key or database key, is made available to the user. This is problematic because the attacker could provide the reference. If authorization is not enforced or is broken, the attacker may access or do things they shouldn’t.

For example, the code has a download.php module that reads and lets the user download files, using a CGI parameter to specify the file name (e.g., download.php?file=something.txt). The developer did not authorize the code, either by error or because he was lazy. This allows the attacker to access any system files the PHP user has access to. For example, the application code or other data left on the server, such as backups. Uh-oh.

A password reset function, which relies on user input, is another common vulnerability. An attacker can change the username field of the URL by clicking on the valid URL. This will make it look something like “admin”.

These are two examples that I have seen “in the wild” in both cases.

Preventive: Use user authorization consistently and adequately, and allow the options. However, the majority of the time, this problem can be avoided by keeping data internal and not relying upon it being passed from clients via CGI parameters. Session variables in most frameworks well serve this purpose.

Common Web Security Mistake #5 – Security Misconfiguration

My experience shows that web servers and misconfigured applications are more common than correctly configured ones. This is likely because there are so many ways to make mistakes. Some examples:

  1. Debugging enabled in production allows you to run the application.
  2. Directory listing enabled on the server can leak valuable information.
  3. Running out of date software (e.g. WordPress plugins or old PhpMyAdmin).
  4. Unnecessary services are running on your machine.
  5. Not changing default passwords and keys. It happens more often than you might think!
  6. The attackers can see error handling information, such as stack traced.
  7. Prevention: Use an automated build and deploy process that can be tested on deployment. Post-commit hooks are the poor man’s solution to security misconfiguration. They prevent code from being sent out with default passwords or development stuff.

Common Web Security Mistake #6 – Sensitive data exposure

This vulnerability in web security concerns crypto and resource protection. Sensitive data should always be encrypted, even while in transit. There are no exceptions. There should be no way for credit card numbers or user passwords to be sent abroad. Passwords should be encrypted and hashed. The crypto/hashing algorithm must be robust. Web security standards recommend RSA (256 bits or more) and AES (2048 bits or more).

Session IDs and sensitive data shouldn’t be sent in URLs. Sensitive cookies must have the secure flag enabled. This is an important point that cannot be overemphasized.


  • In transit: Use HTMLS with a certificate and Perfect Forward Secrecy. Accept no data over non-HTTPS connections. Use the secure flag to place cookies.
  • In storage, This is more difficult. It would help if you first reduce your exposure. You can shred sensitive data if you don’t have it. Theft of data you don’t need is not possible. Don’t store credit card information as you don’t want PCI compliance. Register with a payment processor like Stripe and Braintree. If you have sensitive data, make sure you store it encrypted. bcrypt can be used for hashing. If you don’t know salting or rainbow tables, it is recommended that you learn about them.

Common Web Security Error #7: Missing Function Level Access Control

This is an authorization failure. This means that the proper authorization was not obtained when a function was called on the server. Developers often rely on the server-generated UI and assume that clients cannot access functionality that isn’t provided by the server. This isn’t as easy as it seems. An attacker could always forge requests for the “hidden functionality” and won’t be stopped because the UI doesn’t make this functionality accessible. Imagine that there is a /admin panel. The button is only visible in the UI for admins. If authorization is not present, nothing can stop an attacker from discovering the functionality and using it for their purposes.

Prevention On server-side authorization must always be completed. Yes, always. There are no exceptions.

Common Web Security Mistake #8 – Cross-Site Request Forgery

This is an example of a confused deputy attack in which another party tricks the browser into using its authority. For example, a 3rd-party site can cause the browser to misuse its authority and do something for the attacker.

A 3rd-party site can send requests to the target site (e.g. your bank) using your browser and cookies/session. You can be logged in to one tab of your bank’s homepage and make them vulnerable to this attack. However, another tab could cause your browser to misuse its credentials for the attacker, creating the confused deputy problem. The deputy is the browser that misuses its authority (session cookie) to perform an attack.

Take this example as an example.

Alice, the attacker, wants to make Todd’s wallet lighter by transferring some money to her. Todd’s bank is susceptible to CSRF. Todd must access the URL below to send money:


Once this URL has been opened, Todd is presented with a success page, and the transfer is complete. Alice also knows that Todd frequently visits a site under her control at blog.aliceisawesome.com, where she places the following snippet:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243”; width=”0” height=”0” />

Todd’s browser automatically thinks Alice is linking to an image and issues an HTTP request to fetch it. However, this directs Todd’s bank into transferring $1500 to Alice.

Apart from demonstrating the CSRF vulnerability and displaying how to alter the server state using an idempotent HTTP GET Request, this example is also a severe vulnerability. HTTP GET requests should be idempotent (safe), which means they can’t alter the resource being accessed. Never use idempotent techniques to alter the server state.

Fun fact: Before affiliates became wiser, CSRF was also used for cookie stuffing.

Prevention: Keep a secret token hidden in a form field not accessible from a third-party site. You must verify this hidden field. Some websites ask you for your password when you modify sensitive settings (like your password reminder email), but I suspect this is to protect your abandoned sessions (in an Internet cafe, for instance)


I hope you find this post a bit entertaining and that it has given you a dose of paranoia and increased awareness about website security vulnerabilities.

This is the core message. The old software practices that worked back then for buffer overflows still apply today for pickled Python strings. Security protocols are essential for programmers to write correct programs.

Mark Funk
Mark Funk is an experienced information security specialist who works with enterprises to mature and improve their enterprise security programs. Previously, he worked as a security news reporter.