Security in web applications: the fundamentals that no one can ignore

Every web application is, in practice, an open door to the world. You can pick the lock or leave the key under the rug. Most teams, without realizing it, choose the second option, not because of incompetence, but because security is rarely treated as a requirement from the beginning.

The question I ask any team is simple: if an attacker decided to attack you today, how long would it take? The honest answer is often uncomfortable. And the problem is almost never a lack of technology. It's a lack of foundation.

This article is about those basics. Not about the trendy tool, but about the principles that support a web application that deserves trust.

Why security has become a business problem

There was a time when security was a topic restricted to the infrastructure team. Today it is a CEO, board and reputation problem.

A data leak is not just a bug. It's a headline, it's a fine, it's a lost customer. In Brazil, LGPD brought concrete consequences for those who treat personal data carelessly. But even without regulation, the cost of an incident has always been high, it has only become more visible.

The point is that security is no longer a technical detail and has become a business variable. Those who lead products or technology need to understand this to decide where to invest.

The thesis: security is architecture, not varnish

My position is straightforward. Security is not a layer you add after the product is ready. It is a property that emerges from the decisions you make from the beginning.

Teams that treat security as a final task, a review before launch, a hasty pen test, are just buying the illusion of protection. The pen test finds the symptoms. The architecture defines whether the disease exists.

When security is fundamental, it appears in how you model data, in how you authenticate users, in how you trust (or distrust) input. When it is varnish, it appears in a report that no one reads.

The fundamentals that really matter

I will be pragmatic. There are dozens of possible topics, but a few fundamentals solve most real problems.

Never trust user input

Most classic vulnerabilities, SQL injection, cross-site scripting, parameter manipulation, are born from the same mistake: trusting data that comes from outside.

The rule is simple and non-negotiable: all entry is hostile until proven otherwise. Validate on the server, always. Validation in the browser is user experience, not security, it is trivially circumventable.

Use parameterized queries in the database. Escape outputs according to the context. Treat file uploads as potentially malicious code. These precautions seem obvious, but they continue to be the cause of incidents that make the news.

Authentication and authorization are different things

Authentication answers "who are you". Authorization answers "what can you do". Confusing the two is a recipe for disaster.

The most common error I see: applications that check if the user is logged in, but don't check if they have permission to access that specific resource. The result is the classic problem in which user A can see user B's data just by changing a number in the URL.

Authorization needs to be checked on the server, on each sensitive request, never assumed based on what the interface shows. Hiding a button doesn't protect anything.

Manage secrets as secrets

Passwords, API keys, access tokens. This data doesn't belong in the source code, it doesn't belong in the repository, and it definitely doesn't belong in a versioned configuration file.

User passwords must be stored with hashing algorithms designed for this purpose, not with reversible encryption, much less in plain text. Use consolidated libraries. Homemade encryption is one of the quickest ways to create a problem that you won't detect until it's too late.

Encryption in transit is not optional

All traffic must use HTTPS. There is no reasonable justification for otherwise today. Data that travels without encryption can be intercepted, and this includes credentials.

But be careful: HTTPS protects the path, not the destination. An application can have a green lock in the browser and still store passwords in plain text. Encryption in transit and at rest are distinct layers, and both matter.

What OWASP teaches us

When someone asks me where to start, my answer is almost always the same: start with OWASP.

The OWASP Top 10 is a list of the most critical vulnerabilities in web applications, maintained by the community and updated periodically. It's not a bureaucratic standard, it's a map of threats that actually cause harm.

Its value is not in memorizing the list, but in using it as a common language within the team. When everyone understands what a broken access control or failed security configuration is, technical conversations become more objective and decisions become more informed.

I recommend making the Top 10 part of the process: a light but consistent review that asks "are we exposed to any of these risks?" before each relevant delivery.

Cultural errors that sabotage security

The hardest part of security is not technical. It's cultural.

The first mistake is to treat security as the responsibility of one person or an isolated team. Security is the responsibility of those who write code, those who design products and those who prioritize the backlog. When it becomes someone's job, it becomes no one's job.

The second error is security theater: extensive policies that no one follows, processes that exist in the document but not on a daily basis. Real security is discreet and operational, not a manual in a drawer.

The third, and perhaps most dangerous, is the false sense that "it won't happen to me." Small applications are attacked all the time, often by automation that doesn't choose a target. Being small is not protection.

Security as an advantage, not a cost

There is a better way to look at all of this. Well-done security is not just defense, it is a difference.

In sectors that deal with sensitive data, such as healthcare, finance and the public sector, trust is currency. A product that demonstrates care with data gains an advantage over a competitor that treats the topic with disregard. For public managers, this is even more critical: citizen data is not an asset of the organization, it is a responsibility.

Investing in security fundamentals does not stop innovation. On the contrary, it gives you a solid foundation on which you can build quickly without fear of everything collapsing.

Security is not what you do when you have time. It's what defines whether the product you're building deserves to exist.

If your organization is developing web applications and security is still a topic left until the end, it is worth revisiting this priority. I have other articles on the blog about LGPD, cryptography and secure architecture, and I am always open to exchanging ideas with anyone who takes this topic seriously.