9 Web Security & Data Protection

A web request should expose only the data and actions its user is authorised to access.

Harbour lets customers view bookings through a browser. A mistake in how the application handles a request could expose someone else’s information. This chapter connects web weaknesses to access controls and personal-data responsibilities. A vulnerability can lead to a privacy incident; discovering a flaw alone does not establish that personal data was compromised or notification is required.

9.1 What this chapter covers

By the end you should be able to:

Explain the most common web vulnerabilities (injection, XSS, broken authentication, session issues) at a working level.
Trace how a web attack unfolds, step by step.
Explain core data-protection obligations (privacy principles and mandatory breach notification) with the major regimes as examples.
Connect web weaknesses to the data-protection consequences when they’re exploited.

9.2 Why the web is the front line

A web application is, almost by definition, exposed: it exists to accept requests from strangers over the internet. Every input field, URL, and uploaded file is a place where untrusted data enters your system, and the browser on the other end is a universal client you don’t control. One recurring weakness is trusting input that should never be trusted. Another is failing to check what an authenticated user is allowed to do. Data arriving from a user is treated as if it were safe, and the attacker’s craft is to make that data do something it was never meant to.

9.3 Injection: when data becomes commands

The archetype is injection, and its most famous form is SQL injection. A web application builds a database query using something the user typed, a search term or a login name. If the application glues the user’s input into the query text, an attacker can type input that becomes part of the command itself. Instead of a username they submit a fragment that changes what the query does: turning “find the user named X” into “find every user,” or worse, “delete the table.” The database, unable to tell the developer’s intent from the attacker’s addition, obeys.

Injection generalises beyond databases. Any time untrusted input is fed into something that interprets commands (a database, the operating system, a template engine), the same flaw can appear. And the defence generalises too: keep data and code separate. Rather than build a command by pasting text together, use mechanisms (parameterised queries, prepared statements) that hand the input to the system explicitly as data, so it can never be mistaken for instructions. Validate what comes in, and give the application only the database privileges it needs, so a successful injection does less damage.

9.4 Cross-site scripting: running attacker code in your browser

Cross-site scripting (XSS) is injection aimed at the other users of a site rather than its database. It is worth understanding because it explains how an attacker ends up running code in your browser without ever touching your machine.

A site lets users submit content (a comment, a profile, a message) and displays it back to other users. If the site fails to treat that content as untrusted, an attacker can submit a small script instead of ordinary text. When another user views the page, their browser receives that script as part of the trusted site’s page and runs it in the site’s context, with the victim’s session. Now the attacker’s code, executing as if it were the site itself, may read an accessible session token, act as them, redirect them, or deface what they see. The victim did nothing wrong except visit a page they had every reason to trust. The defence mirrors injection: treat all user content as untrusted, and encode it for the output context so the browser treats it as data. HTML text, attributes, URLs and scripts have different rules; safe framework facilities and sanitisation are needed where rich content is deliberately allowed. OWASP’s XSS guidance explains why one universal escaping function is insufficient.

9.5 Authentication and session weaknesses

The web has a structural quirk that creates its own class of attacks. The protocol underneath is stateless: each request stands alone, with no memory of the last. So after you log in, the server issues a session token (usually stored in a cookie) that your browser sends with every subsequent request to say “it’s still me.” That token is your authenticated session. Anyone who steals it can impersonate you without ever knowing your password. This is session hijacking, and it’s why the sniffing and XSS attacks in this book are so dangerous: they’re often after the token rather than the password. A related trick, session fixation, has the attacker plant a session identifier they already know, then wait for the victim to log in under it. The defences are concrete: send tokens only over HTTPS so they can’t be sniffed, flag cookies so scripts can’t read them and they don’t leak, issue a fresh token at login, and expire and revoke sessions so a stolen one does not remain useful indefinitely. An HttpOnly cookie prevents JavaScript reading that cookie; injected code may still cause authenticated actions. Cookie flags do not make an XSS flaw harmless.

9.6 A valid login is not permission

Suppose Harbour’s customer page accepts a booking identifier. A customer changes that identifier and receives another person’s booking. The login may be genuine and the query parameter safely handled; the missing check is whether this customer is allowed to access that record.

Enforce ownership and role checks server-side on every relevant request. Hiding a button is not access control. Test both a permitted action and an attempt by a different account that should be denied. OWASP’s access-control guidance describes this distinction.

9.7 The other side: protecting the data

Behind every one of these attacks is data. Increasingly it is personal data, and the law now requires its protection. Modern data-protection law sets out principles for handling personal information that recur across jurisdictions: collect only what you need and only lawfully; use it only for the purpose you stated; keep it accurate; secure it; don’t retain it longer than necessary; and let people see and correct what you hold about them. Australia codifies these as the Australian Privacy Principles (APPs) under its Privacy Act; the EU’s GDPR is another version of the same pattern; other countries have their own. The names differ; the shape is consistent. The point for a defender is that security is written into the law. The applicable duties depend on the organisation, data and jurisdiction. A breach warrants investigation; its occurrence alone does not establish that every relevant legal duty was violated.

9.7.1 When it breaks: breach notification

A technical finding starts an assessment, not an automatic notification verdict. Identify the information, the affected people, what occurred, and which laws cover the organisation. Record uncertainty and involve the responsible privacy adviser promptly.

Australia: NDB scheme. For covered entities, an eligible breach generally involves unauthorised access or disclosure, or loss likely to lead to it, where serious harm to an individual is likely. Successful remedial action and exceptions can affect notification. Suspected eligible breaches need assessment: take all reasonable steps to complete it within 30 calendar days. Once there are reasonable grounds to believe an eligible breach occurred, notify the OAIC and relevant individuals as soon as practicable. Thirty days is not a general waiting period. OAIC’s guidance

EU: GDPR. A controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal-data breach, unless it is unlikely to pose a risk to people’s rights and freedoms. A likely high risk generally requires communication to affected individuals without undue delay, subject to exceptions. Processors notify the controller without undue delay. Document breaches and decisions even where regulator notification is not required. EDPB’s notification guidance

These educational summaries were checked in September 2026. They are not a complete statement of the law; other sectoral or contractual obligations may also apply. For a real incident, use the current rules and authorised legal advice.

9.8 From a web flaw to a decision

A report that one customer can read another’s booking establishes an access control problem. Logs showing an unauthorised bulk export add evidence of exposure. Whether notification is required still depends on coverage, information involved, risk or harm thresholds and remedial action.

At Harbour, preserve the export evidence and escalate to the privacy adviser. Do not equate a successful restore with resolution of disclosure, or a lack of actor attribution with a lack of harm. The task is to make a supported, timely decision while technical investigation continues.

9.9 Where this connects

This chapter connects to several others. Authentication is central because the session tokens attacked here are how the web remembers you are logged in, and stealing one sidesteps the password. Network security matters because sniffing and man-in-the-middle attacks are common ways session tokens get stolen, which is why HTTPS matters. Incident & disaster planning shares the breach-notification clock here, the same one that drives a real breach response.

9.10 Questions to consider

In plain words, how does a cross-site scripting attack end up running an attacker’s code in your browser, on a site you trust?
A company is breached and customer data leaks. Under a mandatory breach-notification scheme, what are they obliged to do, and why does that obligation exist at all?
If an attacker steals your active session token, what can they do that they couldn’t with just your username, and what, if anything, can they still not do?

9.11 Separate three decisions

In 15 minutes, distinguish a reported access-control flaw, the supplied bulk-export evidence, and a legally notifiable breach. Record what Harbour’s privacy adviser knows and must still establish. Then contrast the Australian and EU paths using the sources above. Success means no automatic 72-hour rule for every incident, and no claim that a restore resolves disclosure.

Case inputs and checks: Harbour dossier.

9.12 Take it to the AI

Optional: attempt the paper task first. Use only the fictional case, never real messages, credentials, personal information or internal logs. Check any external claims against the primary sources; do not deploy generated rules.

Act as a reviewer of an educational notification decision, not as my legal adviser. Use Harbour’s fictional facts. Separate what is known, what remains uncertain, and which current regulator source addresses the uncertainty. Do not turn a vulnerability report into proof of a notifiable breach. Ask me to justify my decision before offering your assessment.