You already know what OWASP is and where it comes from. Now it's time to answer the question that gives the whole course its meaning: why is web application security so important? If you don't internalize this answer, security will feel like bureaucratic overhead rather than a necessity. In this lesson we will see why the web is such an attractive target, how much a breach really costs, what exactly we are protecting (the CIA triad), and why security must be a cross-cutting property of the entire development process and not a last-minute patch. All of it grounded in what BazarNube truly has at stake.

Note: here we will cover the why and the what. The how of integrating it into the development lifecycle (the secure SDLC) is covered in module 7; in this lesson we only introduce it at a high level.

1. Why the web is a target: the attack surface
2. The value of data and regulatory compliance
3. The real cost of a security breach
4. The CIA triad: what exactly we protect
5. Security as a cross-cutting property ("shift-left")
6. What BazarNube has at stake

A web application is, by definition, public: it is exposed on the internet so that any legitimate user can use it. The problem is that "any user" also includes attackers. Unlike an internal program, your web application is accessible 24/7 from anywhere on the planet.

We call attack surface the set of points through which an attacker can try to get in or interact with the system. The more entry points, the larger the surface. A modern web application has many:

• Each API endpoint (routes such as /login, /products, /payments).
• Each form and input field in the frontend.
• The HTTP headers, cookies, and tokens.
• The third-party dependencies (npm libraries, Java packages, and so on).
• The infrastructure that hosts it (containers, cloud configuration).

The practical consequence is devastating: it only takes one of those points being vulnerable to compromise the entire system. The defender has to protect every point; the attacker only needs to find one. That asymmetry is the underlying reason why web security is so demanding.

Attackers don't attack for sport (usually): they attack because there is something valuable to obtain. And web applications guard precisely that: data.

• Personal data: names, emails, addresses, phone numbers. Useful for identity theft, spam, or resale.
• Credentials: usernames and passwords, which get reused on other services.
• Financial data: cards, accounts, payment histories. The most direct target of fraud.

Because this data is sensitive, there are regulations that require protecting it. You don't need to master them now (some are covered in later modules), but you should recognize them at a high level:

The key takeaway: security is not just a good technical idea, it is a legal obligation. Failing to comply with GDPR or PCI-DSS can lead to heavy fines and the loss of your ability to operate (for example, your payment provider dropping your service).

When a breach occurs, the cost goes far beyond "fixing the bug". It helps to see it broken down, because people often only think about the technical part, which is usually the smallest:

For a startup, the blow is especially dangerous: a large company can absorb a fine and a reputational crisis, but a young startup may not survive a serious breach. Trust is its most fragile asset, and it can be lost in a single day.

When we say "protect", what are we protecting? Information security is classically summed up in three properties, known by the acronym CIA (nothing to do with the agency): Confidentiality, Integrity, Availability.

The CIA triad is an enormously useful analysis tool: for any risk, ask yourself which of the three properties it threatens. You'll find that almost everything fits into one (or several) of them. It is a vocabulary we will use throughout the course, and it connects directly with the threat model we will build for BazarNube.

Let's see it with a snippet of code. This endpoint of the BazarNube API has a classic problem that compromises confidentiality and integrity:

The problem: any authenticated user can request /api/orders/1, /api/orders/2, and so on, and read other people's orders (this breaks confidentiality). The check for ownership of the resource is missing. A more secure version would be:

Here requireAuth guarantees there is an authenticated user, and the check order.userId !== req.user.id guarantees that they only see their own orders. Don't worry about mastering this pattern now: we will study it in depth in module 3 (access control). The goal here is for you to see how a concrete coding decision translates into a property of the CIA triad.

A widespread historical mistake is treating security as the last phase before launch: everything gets built and, at the end, a security review is done "to see if it passes". This approach fails for two reasons:

1. The flaws are already baked into the design. Many security problems stem from architectural decisions made at the start. Detecting them at the end means rebuilding, not patching.
2. Fixing late is extremely expensive. Correcting a flaw in production costs far more — in time and money — than avoiding it in the design phase.

The alternative is summed up in an idea called "shift-left": moving security considerations toward the beginning of the process, not toward the end. If you picture the development lifecycle as a line from left (idea/design) to right (production), "shift-left" means thinking about security from the far left.

Notice the dotted lines: security touches every phase, not just one. It is a cross-cutting property, like quality or performance: it is not something you "add" at the end, but something that permeates every decision.

Here we only introduce the idea. How it is organized in practice within the software development lifecycle (the secure SDLC, threat modeling, DevSecOps) is the subject of module 7; for now it is enough to internalize the principle: before and during, not only at the end.

Let's apply all of this to our case. Remember: BazarNube is a marketplace with customer data, payments, and a legacy billing module in Java. Together with Lucía, Marc, and the SRE, you start mapping which concrete risks the company faces, classifying them with the CIA triad. This is the seed of the findings backlog we will build throughout the course:

For a startup like BazarNube, the three most feared consequences come down to this:

• Customer data: a leak would destroy the trust that is so hard to win.
• Payments: a card incident would mean penalties and could leave them without a payment provider.
• Reputation: in a competitive market, "the store that got hacked" is a label that scares away customers and investors.

With this initial map, the team understands that security is neither optional nor cosmetic: it is a condition for surviving and growing. And now it has the motivation to dive into OWASP's concrete tools.

• Thinking "no one is going to attack me". Attacks today are largely automated: bots crawl the internet looking for any vulnerable application, regardless of the company's size. Being small doesn't make you invisible; it makes you an easy target.
• Reducing security to confidentiality. Many people only think about "don't let them steal data". Integrity and availability are just as important: a manipulated price or a store that's down are also serious incidents.
• Leaving security for the end. It's the most expensive mistake. Apply the "shift-left" principle: think about security from the design stage.
• Ignoring compliance until it "becomes relevant". GDPR and PCI-DSS apply from the very first customer, not once you're big. Ignoring them at the start creates a debt that explodes at the worst possible moment.
• Tip: for any new feature, ask yourself: "which CIA property does it put at risk, and who would want to attack it?". That's the first step of threat modeling.

Exercise 1. For each incident, indicate which property of the CIA triad is primarily compromised: (a) an attacker downloads the email list of all customers; (b) an attacker modifies the balance of their wallet in the store; (c) a massive attack leaves the site inaccessible for hours.

Exercise 2. BazarNube is going to add an "export my orders to PDF" feature. Before coding it, apply the "shift-left" principle: list at least two security questions you should ask yourselves in the design phase (not at the end).

Exercise 3. Explain, in 4-6 lines, why a security breach can be more dangerous for a startup like BazarNube than for a large corporation, using at least two of the cost types seen in section 3.

Solution 1. (a) Confidentiality (data that should be private is accessed); (b) Integrity (data — the balance — is altered without authorization); (c) Availability (the service stops being accessible).

Solution 2. Examples of design questions (two are enough):

• How do we ensure that a user can only export their orders and not someone else's? (access control, confidentiality).
• Could the PDF include sensitive data (such as payment data) that shouldn't appear? (data minimization).
• Could PDF generation be abused to overload the server if someone invokes it en masse? (availability).
• Where is the PDF temporarily stored and who can access it? Raising these questions before coding avoids rebuilding the feature later.

Solution 3. A large corporation can absorb the legal and regulatory costs (a fine) and the reputational costs (an image crisis) thanks to its size, its reserves, and its consolidated customer base. A startup like BazarNube, by contrast, depends critically on the trust of its first customers and investors: reputational damage can trigger a mass exodus of users, and a high operational cost (halted sales, a team firefighting) can drain its scarce cash. The sum can push it straight into closure, something far less likely at a large company.

In this lesson you have understood why web security is critical: a public application has a huge, asymmetric attack surface, it guards valuable data subject to regulations such as GDPR and PCI-DSS, and a breach brings technical, legal, reputational, and operational costs that can sink a startup. You have adopted the CIA triad (confidentiality, integrity, availability) as a tool for classifying risks, and the "shift-left" principle: security is a cross-cutting property, not a final phase. And you have drawn the first risk map of BazarNube, the seed of the backlog we will keep expanding.

With this we close module 1. You now know what OWASP is, where it comes from, and why security matters. In module 2 we will move from theory to the toolbox: we will go through OWASP's main projects — starting with the famous OWASP Top Ten, the list of the ten most critical risks — to start putting concrete names to the threats we have only sketched for BazarNube so far.