blank
6
Sep

The first safety barrier begins at the frontend

Most applications protect their databases, their backend applications, their apis … but does anyone protect the frontend of their applications? Can I suffer attacks this way?

After having worked for many small, medium and large clients, I have heard, from both business people and “expert” technicians, that the frontend only paints and colors, that only the safety of the backend matters, it is not necessary to include a test quality, etc. But the reality that we find when a user accesses our application, the mobile or web interface, will be the first one that deals with.

The two concepts that we must take into account at the security level on our front are:

  • Holes and information of our system
  • Direct attacks on our front

blank

When we talk about these gaps and information, we are referring to those attacks that will go to other parts of the system, for example a database, but that will be able to carry them out or obtain information, because we do not have our project adequately protected or developed. The clearest example would be as if our front were the walls that protect our house, and on the one hand we were dedicated to putting large windows without curtains and also, some hole than another through the walls..

When we talk about the windows, we would be referring to the information that the user could obtain through the browser of the versions of our server, open apis, backend structure, database location, etc. With this, the frontend will not suffer attacks but it would allow them to discover more easily, vulnerabilities of our system.

As for the gaps in the wall, we would be referring, for example, to an SQL Injection through our forms. Ideally, from our website, we treat and validate all data, before sending it to the backend, to avoid these and many other problems. Although this does not remove, that also the back must have taken into account all the possibilities, to prevent the database from being corrupted, to make attacks on the server, etc. That is, what we intend to do from the development of the web, is not to suggest the possibilities of attack, filter most of the problems that could reach the backend and give more stability to our application.

As for the possible direct attacks on our website, the most obvious cases we could find are:

  • Obtaining information
  • Uncontrolled errors in our application
  • Vulnerabilities in sections

The great advantage we have today, is that some of the JS frameworks / libraries with which we can work, have integrated security systems to manage part of these vulnerabilities. Although, the other part, are good development practices.

In the event that we are developing a new application or want to review an application that we have already deployed, the most efficient, would be to use some of the free or paid tools, which would analyze a part of these vulnerabilities. Although we must take into account that depending on the architecture and frameworks we have used, we must choose some options or others. An example of this would be for example WordPress, where we would have specific tools to analyze it, such as:

But do not forget, that these tools only analyze the general errors, and that if we have a project large enough and important, we must have a specialist reviewing the project manually.

Leave a Reply