There is an expression that perfectly captures the day an application gets hacked: being caught off guard. It is that moment when the problem has already happened and there is no longer any way to pretend everything was under control. With that spirit—direct and without unnecessary alarm—Danrley Pereira and Pedro Druck took the stage at the DW Corp track during Campus Party Brasil 2025 (CPBR17), in Brasília, to talk about practical web security.
This recap keeps the same tone as the talk: no intimidating jargon, just the essentials every developer should know before putting something online.
Security Is Not a Senior-Only Luxury
One idea ran through the entire session: security is not a switch you turn on at the end of a project, nor is it the exclusive responsibility of senior engineers. It starts with the first line of code. The earlier you think about how your application could be abused, the cheaper and simpler it is to protect it.
The good news is that most real-world attacks are not sophisticated. They are the same mistakes repeated over and over, and there is already a map of them.
The OWASP Top 10 in Plain English
That map is the OWASP Top 10—a community-maintained list of the most common categories of security flaws in web applications. Think of it as a checklist of what tends to go wrong: broken access control, exposed sensitive data, injections, security misconfigurations, outdated components, and more.
The value of the list is not in memorizing it, but in using it as a lens. Before shipping a feature, it is worth asking: where does this change touch each of these risks? That is how Danrley and Pedro guided the audience—taking items from the Top 10 and showing how they appear in everyday code.
Injections: The Classic That Still Brings Systems Down
Injection happens when data supplied by a user is interpreted as a command. The classic example is SQL injection: an innocent search field that, if handled improperly, allows someone to rewrite a database query. But the principle applies anywhere input becomes execution—commands, HTML, or queries.
The defense demonstrated in practice was simple and consistent: never trust user input. In a Flask back end, that means using parameterized queries instead of concatenating SQL strings, and validating everything that comes in. In a React front end, it means not injecting raw HTML from users and letting the framework escape the content itself. The golden rule: treat all external data as suspicious until proven otherwise.
Access Control: Who Can Do What
Another frequent cause of incidents is broken access control—when the system forgets to check whether a user is actually allowed to perform an action. A classic example is changing an ID in a URL and ending up viewing someone else’s order.
The point raised on stage was that authentication and authorization are different things. Authentication means knowing who the user is; authorization means deciding what they are allowed to do. Hiding a button in the front end is not security—the permission check must always happen on the server, on every request.
OAuth2 and JWT Without the Mystery
The part that generated the most questions was about login. OAuth2 and JWT can sound mysterious, but the speakers broke them down with simple analogies.
OAuth2 is an authorization protocol: instead of giving your password to every application, you authorize it to receive an “access card” with limited permissions. This is what happens when you choose “Sign in with Google.”
JWT (JSON Web Token) is the format of that card: a signed token that carries information about who you are and what you are allowed to do. Because it is signed, the server can verify whether it has been tampered with. In the React and Flask example, the front end stores the token and sends it with every request; the Flask back end validates the signature and expiration before granting access to anything. The precautions highlighted were: do not put sensitive data inside the token, set a short expiration time, and always validate it on the server—never trust only what the client says.
What to Take Away
Danrley and Pedro’s final message was reassuring: you do not need to be a security specialist to significantly improve your application’s security. You need a few habits—questioning user input, checking permissions on the server, understanding what your tokens contain, and keeping dependencies up to date.
Security is less about paranoia and more about consistent care. And taking care of it early is the best way to avoid being caught off guard.
