A page is rarely built from your own code alone. It pulls Bootstrap 2,007 from a CDN, analytics from a vendor, a map from another company and comments typed by strangers. Every one of those inputs is a way in. The browser's baseline defense is the same-origin policy: a script from https://shop.example cannot read the DOM, cookies or network responses of https://bank.example. An origin is the triple of scheme, host and port, so http://shop.example and https://shop.example:8443 are both different origins from https://shop.example.
On top of that policy, HTML and HTTP give you element attributes and response headers, each aimed at a class of attack: crossorigin and CORS for controlled cross-origin reads, integrity against tampered CDN files, referrerpolicy against URLs leaking through the Referer header, nonces and Content Security Policy against cross-site scripting (XSS), Permissions Policy against embeds misusing powerful features, and sandboxed iframes and Trusted Types for untrusted frames and DOM-based XSS. XSS, in which an attacker gets their JavaScript to run in your origin, is the most damaging front-end bug, because the injected code can do anything your own code can.
None of these replaces server-side validation, CSRF tokens or SameSite cookies, and all of them assume HTTPS, which Securing with HTTPS sets up. Treat them as defense in depth: when an escaping bug lets markup through, a strict policy still stops the payload from running.