Web application security: the architecture explained for beginners

Those who are starting to develop for the web tend to imagine security as something that is added at the end: an antivirus, a firewall, a plugin. It's a comfortable image and completely wrong. Security is not a piece that fits into the finished product, it is a property of the way the product was built.

The difference is fundamental. A web application is like a house. You don't make a house safe by installing an expensive lock on the front door if the walls are cardboard and the windows don't close. Security comes from the structure, not from an accessory glued on top.

This article explains, without assuming prior knowledge, how the architecture of a web application determines its security. It's for beginners who want to understand the right fundamentals from the beginning, before getting into habits that are costly to undo later.

The anatomy of a web application

To talk about security, you first need to understand the parties. A web application has, simply put, three layers, and each one has its role in security.

The client is what runs in the user's browser: the screens, the buttons, what the person sees and touches. The server is where the real logic happens, away from the user's eyes. And the database is where the information is stored.

Between these layers, data travels across the network. This simple structure already contains the most important security lesson for beginners, and that's where we'll start.

The golden rule: never trust the customer

If you remember just one principle from this article, remember this: everything that runs in the user's browser is under the user's control, and therefore can be manipulated. The customer is enemy territory.

Beginners make the mistake of placing security checks on the client. They validate the form in the browser, hide a button from those who do not have permission, check whether the value is valid on the screen. All of this is good for the user experience, and absolutely useless for security. An attacker simply ignores the screen and talks directly to the server, sending whatever he wants.

The architectural consequence is clear: every security decision needs to be made on the server. Data validation, permission checking, business rules, all of this lives on the server, where the user cannot reach. The customer suggests; the server decides. This separation is the backbone of web security.

The two pillars: who you are and what you can

Practically all application security is based on two concepts that beginners tend to confuse.

Authentication is proving who you are. It's the login: username and password, perhaps a second factor. It answers the question “are you really who you say you are?”.

Authorization is defining what you can do once identified. It answers the question “are you allowed to do this?”

Confusion between the two generates one of the most common failures there is. A system confirms the login (authentication) but forgets to check, in each action, whether that user has the right to that data (authorization). The result is the classic attack of changing a number in the URL and accessing someone else's information, a flaw that has been at the top of OWASP's lists for years.

In architecture, this means two distinct checks. Confirming identity at the entrance is not enough. Permission must be checked each time a resource is accessed. Forgetting the second is like checking the badge of whoever enters the building but leaving all the rooms unlocked.

Protecting data in transit and at rest

An application's data exists in two states, and both need protection.

In transit is when data travels between the client and server over the network. Here, the protection is encryption of communication, via HTTPS. Without this, anyone on a shared network, public Wi-Fi, for example, can intercept and read what is being transmitted, including passwords. HTTPS today is a basic and non-negotiable standard.

At rest is when the data is stored in the database. The most critical protection for beginners to understand is the handling of passwords: they should never be stored as the user typed them. They go through a process called hash, which transforms them into something irreversible. So, even if the bank is leaked, the passwords are not readable. Saving passwords in plain text is perhaps the most common mortal sin for beginners.

The classic threats that architecture prevents

Some attack categories are so common that every beginner should know them by name. They appear on the OWASP list, the global reference for web application risks.

Injection happens when data sent by the user is interpreted as commands by the system. The classic case is SQL injection, where a form field is used to trick the database. The architectural defense is to never mix user data with commands directly, always treating input as data, never as instruction.

Cross-site scripting (XSS) occurs when malicious code sent by one user ends up running in another's browser. The defense is to treat and escape everything that comes from outside before displaying it on the screen.

The common pattern of these threats is the same principle as before: data coming from outside is not trustworthy and needs to be validated and processed on the server before any use. Secure architecture is, to a large extent, architecture that systematically distrusts input.

Reflection for those just starting out

The beginner's most dangerous mental trap is "my project is too small to attack." It's exactly the opposite. Most attacks don't choose targets, they are automated bots scanning the internet for known flaws. A small, poorly protected project is precisely the easiest target for these scans. No one needs to want to attack you; all it takes is an open door found by chance.

There is also the legal dimension that beginners ignore. In Brazil, LGPD makes those who collect people's data responsible for protecting it, regardless of the size of the project. Building securely from the beginning is not just good technical practice, it is a legal and ethical responsibility to the people who entrusted you with their data.

You don't need to master everything to get started right. The architectural fundamentals, never trusting the client, separating authentication from authorization, encrypting communication, protecting passwords, validating all input, already put a beginner ahead of a huge number of applications on the market. Security, in the beginning, is less about advanced techniques and more about not making the basic mistakes you know how to avoid.

Learning to draw safely from the first project is an investment that pays for itself many times over. Remaking a system built without these foundations is expensive and painful; building it right from the start is just a matter of habit.

If you're starting to develop for the web and want to build on the right foundation, there are other blog articles on authentication, OWASP, LGPD, and secure architecture that go into more depth on each of these points. If it's a moment of learning or decision-making in your organization, it's worth talking about.