Computer Security vulnerabilities


A security flaw or vulnerability designates in computing any weakness in a system (eg a web application). Which would allow a potentially malicious person to alter the normal operation of the system or even to access unauthorized data.

The cause is usually unintentional and can lie in the software design or a deeper problem at the hardware level.


Security vulnerabilities are important elements to take into account in the development of any IT project. A set of good practices and reflections already makes it possible to protect against it naturally.

The OWASP, or Open Web Application Security Project, is a foundation that publishes and recommends a set. The information concerning security vulnerabilities on the WEB.

In particular, it publishes a top 10 security breaches every 3/4 years. The latest, from 2017, includes the following flaws as major flaws:


An injection consists in sending and executing code by the server. The idea is to capitalize on a weakness in the writing of the code of the backend part. That allows a user to recover data to which he is not supposed to have access.

A classic example is that of SQL injections. The example below illustrates a possible flaw by altering the generated SQL query. Its initial purpose if the user passes unchecked parameters to it.

Broken Authentication

The most answered security vulnerabilities are often the simplest and sometimes even exploit human vulnerabilities via, for example, “scams” or scams aimed at recovering the user’s password that the user enters deliberately believing that he is on a site. benevolent.

This flaw includes the use of a known or sufficiently weak password (little complexity) for software to find it easily. Or even that precisely the authentication system of a system is based solely on a password and not a couple password/validation by telephone for example.

Exposure of sensitive data

The idea here is for an attacker to access or alter poorly protected data. It is very important, for example, to properly encrypt the passwords stored in the database of your project. Indeed, even if tomorrow a person succeeds in accessing the database, it is important that this one cannot read or decipher the sufficiently encrypted passwords, and thus limit the value of the loot that this one would have recovered.

XML External Entities (XXE)

Communication between two elements based on XML exchanges is a relatively old process, although still in use. (See article: REST API vs SOAP vs Graph). By extension of this, it happens that it is old and potentially misconfigured systems that use this technology.

It then becomes possible to send XML containing malicious code, making it possible to choose between recovering files (password encryption key for example), accessing private resources, or even generating denial attacks of service on potentially very large file reading.

Broken Access Control

Again, the idea is quite simple: try to access unauthorized resources. It happens in some applications that role management and security levels are poorly implemented. Thus, one can imagine, for example, a use case where a page is supposed to be only accessible to administrators. To go to this page, the user must first go through a login screen. However, the flaw could lie in the fact that if a person enters the final destination URL, here is not the place to verify the administrator role and therefore the page is accessible by all.

Bad security configuration

Poorly configured services are a source of potential security vulnerabilities. It is sometimes necessary to short-circuit certain behaviors of its application (ex: “hard” authentication) during development to facilitate its development. It is imperative to remove this kind of behavior during a production phase.

This can be an example code left in place. Which serves as a demonstration in development but which is a real open door in production. Or, leave access to the exploration of the application directory. Thus make it possible for an attacker to recover the source codes.

Cross-Site Scripting XSS

In a web application in which the user can enter information (ex: a forum) and that these can therefore generate HTML or JS to be displayed on other pages, (ex: a comment, etc.), XSS flaws may be present. The idea is that thanks to these user inputs, a malicious person can write code that could be executed by other users on their workstations. It then becomes possible to redirect the user to another site or to steal their connection cookies.

Insecure deserialization

In the case of a modern application, the operation is generally as follows: a front part communicates with a back part via APIs. To authenticate the user, the back part sends a unique authentication token back to the front. This token contains all of the user’s information: name, roles, etc. If the token manages to be decrypted and then re-encrypted using a weak encryption key, it then becomes possible to modify its role in the application and to have access to administrator resources.

Use of components with known security vulnerabilities

The problem is self-explanatory, you should not use components with known security vulnerabilities, and if this is already the case, you should try to update or change the components in question.

Lack of administration and log

Although it is not a flaw in itself, the lack of a monitoring tool is a real problem in the fight, research, and resolution of a security breach. How do you find the source of a problem without analytics data, and even worse, how do you know about a flaw that is currently being exploited?

Flaws have always existed in computer systems and always will. The heart of error is often human, and the best solution to guard against it is to be aware, rigorous in your work and to take the necessary measures. This is where Next Decision comes in to carry out secure projects.

Leave a Comment