Application vulnerabilities: why they persist and how to lead defense

Most security incidents that make the news do not exploit a sophisticated, novel flaw. It exploits something that has been known for years, documented, with a fix available, that simply has not been addressed. The vulnerability was not hidden. It was on the to-do list that no one prioritized.

This is uncomfortable to admit, but it is the truth that matters most to those who lead. Application vulnerability categories are remarkably stable. OWASP, a global reference in application security, has been publishing the same list, with small variations, of the most common risks for more than two decades. If the problems are known and the solutions exist, why do they persist?

The answer is not technical. It's management. Application security fails less because of a lack of knowledge and more because of a lack of priority, process and culture. This text is about that, written for those who decide where the team spends time, not just for those who write code.

What is a vulnerability, without mystification

A vulnerability is a weakness in a system that can be exploited to cause damage: leak data, alter information, bring down the service, take control. It doesn't need an evil genius to be explored. Most are discovered by automated tools that scan the entire internet looking for exactly the same repeated errors.

This is why "no one will be interested in our application" is a dangerous phrase. Scanning is automatic and indiscriminate. What decides whether you are a target is not the relevance of your business, it is the existence of the flaw.

And the cost of an exploited flaw goes far beyond the technical. There is service interruption, loss of trust, damage to reputation and, in Brazil, exposure to LGPD when personal data is involved. An untreated vulnerability is a business liability, not just a bug.

The OWASP Top 10 as a priority map

The OWASP Top 10 is the most sensible starting point for any organization. It is not a complete security checklist, but it is the community's consensus on the risks that appear the most and cause the most damage. It is worth knowing its main categories, translated into the language of those who decide.

Broken access control

The most common category. It happens when the system doesn't properly check who can do what. A user accesses another's data by changing a number in the URL; an ordinary person performs an action that should be carried out by an administrator. It's the "the door is unlocked for those who know how to push" failure.

Cryptographic flaws

Sensitive data traveling or stored without adequate protection, passwords stored reversibly, connections without encryption. In the context of the LGPD, this is especially serious: personal data exposed by absent or poorly performed encryption is a failure that the law demands.

Injection

When data sent by the user is interpreted as a command by the system. The classic case is SQL injection, in which a form field becomes an instruction for the database. It is one of the oldest and still most exploited errors, because it continues to be committed.

Insecure design

A more recent and important category: flaws that are not in the code, but in the design. You can seamlessly implement an architecture that was insecure by design. Security needs to be on the drawing board, not just in the final review.

Security misconfiguration

Servers with default configuration, exposed administrative panels, error messages that reveal internal details, permissions that are too broad. Often there is no wrong code, there is a poorly configured environment, which is just as dangerous.

Vulnerable and outdated components

Almost all modern software is built on top of third-party libraries. When one of these dependencies has a known flaw and is not updated, your application inherits the problem. Maintaining inventory and updating these parts is ongoing work, not occasional work.

The remaining categories, identification and authentication failures, data and software integrity failures, logging and monitoring failures, and server-side request forgery, complete the list. The point is not to memorize the ten. It's understanding that there is a public map of the most likely risks, and that ignoring it is a choice.

The thesis: security is a management decision, not an end-of-project task

My position is that the biggest weakness of most applications is not technical, it is organizational. Developers, in general, know what injection and broken access control are. What's missing is time, priority and a process that makes safety part of the work, not an extra thing that can be done "when possible".

When security is treated as a step at the end of the project, a hasty audit before launch, it loses. Deadline pressure always wins over care that has no clear owner. The costly failures are the ones that were known and deprioritized, not the ones that no one saw.

Technology leadership that takes security seriously doesn’t ask for team heroism. Build a system in which doing the right thing is the easiest way: code review with a security eye, automated tests that catch common flaws, updating dependencies as a routine, and the clarity that delivering insecure is not delivering.

How to reduce vulnerabilities in practice

Effective defense is made of habits, not a single grand project. Treating security as part of the development cycle, rather than as an isolated event, is what differentiates mature organizations.

Some practices have a disproportionate return. Validating and treating all user input as untrusted eliminates entire classes from injection. Applying the principle of least privilege, giving each part of the system only the access it needs, limits the damage when something fails. Keeping dependencies up to date closes the door on known flaws. Recording and monitoring allows you to discover an incident in hours, not months.

It is also worth adopting automated scans in the development flow itself, so that common flaws are identified before reaching production. Automation does not replace thinking, but it takes away the repetitive work of looking for errors that have already been cataloged.

For systems that handle citizen data, common in the public sector, this connects directly to LGPD and service continuity. A failure there is not just a technical risk; It is a legal and public trust risk.

Limits and pitfalls

It is honest to recognize that absolute security does not exist. The goal is not to make the application tamper-proof, it is to make it expensive enough to attack and resilient enough to detect and respond when something goes wrong.

The most common trap is security theater: extensive policies, compliance documents and expensive tools that give a sense of protection without reducing real risk. Compliance on paper is not security in practice. What protects is what is implemented and tested, not what is written.

Another trap is treating security as the exclusive responsibility of a specialist or an isolated area. When security is "the security people's problem", the rest of the team loses responsibility. The real defense is distributed: everyone who writes or configures something has a role.

Known and ignored vulnerability is a decision, not an accident

The phrase worth remembering is simple: almost every exploited vulnerability was known and avoidable. This is scary, but also liberating, because it means most of the risk is within our control. We do not depend on predicting the unprecedented attack. We depend on treating what we already know.

Leading application security is, in essence, leading priority. It's deciding that delivering insurance is part of delivering, that updating dependencies is not a waste of time, that known and overlooked failure is a decision that someone responds to. OWASP gives us the map. What is missing, almost always, is the will to follow it.

If your organization treats security as a final step rather than an ongoing practice, it's worth reviewing this process before the next incident does it for you. I have other texts on the blog about security, LGPD and secure development, and I am available to talk to whoever is structuring this front.