Mariko Kosaka on web.dev

Baseline features you can use today

2023-05-10T00:00:00Z

The web is always evolving and browsers update constantly to give developers new tools to innovate on the platform. Things that previously required helper libraries become part of the web platform and supported on all browsers, along with shorter or easier ways to code design elements.

While this constant evolution and adaptation is helpful, it can also bring confusion. It can be difficult to navigate all these updates. As developers, we have questions like, "When will all browser engines support this new feature?" "When can I actually start using those features in my production code?" "For how long should we support older browsers?"

The true answer is "it depends". What is needed and what is usable really depends on your user base, tech stack, your team structure, and supported devices. But, one thing we all agree, is that the current landscape of the web can make it difficult to make those decisions.

The Chrome team is collaborating with other browser engines and the web community to bring more clarity. This includes our work on projects like Interop 2023 which helps to improve interoperability of a set of key features. But what about features landed in the past few years? Are experimental features we learned about two years ago ready to use?

In this post, I want to highlight some features that are now available to all major browser engines for the past two major versions. This is the cut-off point where we feel that the majority of developers will feel a feature is safe to use, and is the feature set we're calling Baseline. For more, please see the announcement of Baseline here.

The dialog element #

The <dialog> element is a new HTML element to create dialog prompts such as popups and modals.

Browser support

Chrome 37, Supported 37
Firefox 98, Supported 98
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

To use it, define the modal element, then open the dialog by calling the showModal() method on the dialog element.

<dialog id="d">
  <form method="dialog">
    <p>Hi, I'm a dialog.</p>
    <button>ok</button>
  </form>
</dialog>

<button onclick="d.showModal()">
  Open Dialog
</button>

As a native HTML element, features like focus management, tab tracking, and keeping the stacking context are built in. For more, read Building a dialog component.

Individual CSS transform properties #

Using CSS transforms is a performant way to add a movement to your site.
You might be familiar with writing CSS transforms with three properties in one line.
With individual transform properties you can now specify transform properties individually. This comes in handy when you are writing complex keyframe animations.

.target {
  translate: 50% 0;
  rotate: 30deg;
  scale: 1.2;
}

Browser support

Chrome 104, Supported 104
Firefox 72, Supported 72
Edge 104, Supported 104
Safari 14.1, Supported 14.1

Source

For an in-depth explanation of this change, read Finer grained control over CSS transforms with individual transform properties.

New viewport units #

On mobile, viewport size is influenced by the presence or absence of dynamic toolbars.
Sometimes you have a URL bar and navigation toolbar visible, but sometimes those toolbars are completely retracted.
The actual size of viewport will be different depending on whether the toolbars are visible or not.
New viewport units like svh and lvh give web developers finer control when designing for the mobile. You can learn more in the article The large, small, and dynamic viewport units.

Browser support

Chrome 108, Supported 108
Firefox 101, Supported 101
Edge 108, Supported 108
Safari 15.4, Supported 15.4

Deep copy in JavaScript #

In the past, to create a deep copy of an object with no reference to the original object, a popular hack was JSON.stringify combined with JSON.parse. This was such a common hack that V8 (Chrome's javascript engine) aggressively improved the performance of this trick. But, you don't need this hack anymore with structuredClone.

const original = {id: 0, prop: {name: "Tom"}}

/* Old hack */ 
const deepCopy = JSON.parse(JSON.stringify(original));

/* New way */
const deepCopy = structuredClone(original);

Browser support

Chrome 98, Supported 98
Firefox 94, Supported 94
Edge 98, Supported 98
Safari 15.4, Supported 15.4

Source

Please refer to Deep-copying in JavaScript using structuredClone for more details.

The `:focus-visible` pseudo-class #

As web developers, we all are familiar with that "focus ring" that shows up when you are navigating a page with a keyboard or clicking on input elements. It is a necessary feature for accessibility but sometimes it gets in the way of the visual design for different users. The :focus-visible CSS pseudo-class checks if the browser believes that the focus should be visible. You can now specify styles for only when focus should be visible.

/* focus with tab key */
:focus-visible {
    outline: 5px solid pink;
}

/* mouse click */
:focus:not(:focus-visible) {
    outline: none;
}

Browser support

Chrome 86, Supported 86
Firefox 85, Supported 85
Edge 86, Supported 86
Safari 15.4, Supported 15.4

Source

Check out the Focus section on Learn CSS for more information.

The TransformStream interface #

The TransformStream interface of the Streams API makes it possible to pipe streams into one another.

For example you can stream data from one place, then compress the data stream to another location as the data gets passed. The article Streaming requests with the fetch API walks you through this sample use case.

Browser support

Chrome 67, Supported 67
Firefox 102, Supported 102
Edge 79, Supported 79
Safari 14.1, Supported 14.1

Source

Wrap up #

There are many more features that recently became interoperable and stable to use on the web platform. Going forward we will work with the WebDX Community Group to bring more clarity to these Baseline feature sets. Please check out web.dev/baseline for ongoing details.

If you want to stay up-to-date, our team is publishing articles when a feature becomes interoperable, and publish monthly updates on what's going on the web platform from experimental features to newly interoperable.

We are always curious if what we are doing helps you, or if you need different kinds of support, so please reach out to us at WebDX Community Group.

Compat 2021 Holiday Update: presents for developers before the end of the year

2021-12-13T00:00:00Z

The end of the year is near, and it's time for a final update on Compat 2021—an effort to eliminate browser compatibility problems in five key focus areas.

>90_%

score in all browsers

Since our last update, we’ve continued to see improvements in all browsers. All browsers started with much lower test scores at the beginning of the year, but now all browsers have surpassed 90%! This means the web platform has significantly improved interoperability of the five focus areas.

A snapshot of Compat 2021 Dashboard (experimental browsers).

Contributions to browser engines are made not only by browser vendors, but also others in the web community. For this project, we particularly want to thank Igalia for their involvement and continued work to improve the scores. Igalia has contributed to improving all five focus areas of Compat 2021.

On wpt.fyi, the test results dashboard, there’s now a filtered test results view showing all of the tests included in Compat 2021, and also views for Chrome, Firefox, and Safari comparing the results to our last update in July.

Let’s take a look at the improvements in each area!

CSS flexbox #

flex-basis: content is now on its way to all browsers, with implementations landing in Chromium and WebKit. (The content value was already supported by Gecko.)

In Chromium, an issue with flexbox sizing is fixed, matching the spec and Gecko’s behavior. And in Gecko, several issues affecting Compat 2021 are fixed, including an issue with percentage height on flex items. Finally, in WebKit, support for more alignment property values (left, right, self-start, self-end, start, end) is now added, and a lot of improvements were made for absolute positioning, also improving the flexbox test results in Compat 2021.

CSS Grid #

The use of CSS Grid on the web continues to grow, as can be seen in both the 2021 Web Almanac and Chrome’s usage metrics.

The launch of GridNG in Chrome and Edge 93 resolved many long standing issues with Grid, closing an impressive 38 issues in Chromium’s bug tracker. Together with many smaller improvements that followed, the Compat 2021 score for Grid in Chromium improved by 3% to 97%. This work was led by the Edge team at Microsoft.

An absolute positioning bug affecting Grid was fixed in Gecko, and many fixes have landed in WebKit, leading to a 1% improvement for Firefox and 3% improvement for Safari on the Grid tests.

CSS `position: sticky` #

In our last update, we noted that position: sticky was the first area where any browser (in this case Chrome and Edge) reached 100% passing tests. Now, following a number of fixes in WebKit’s implementation, Safari also scores 100% for these tests. Most of these improvements were included in Safari 15.

CSS `aspect-ratio` property #

Cross-browser support for defining the aspect ratio (width-to-height ratio) of elements has continued to improve, with Compat 2021 scores reaching 99%, 97% and 95% for Chrome/Edge, Firefox and Safari respectively. Most of the improvements are not with the aspect-ratio property itself, but rather with how width and height attributes are mapped to a default aspect-ratio value for elements. This was implemented for multiple elements in WebKit, and <canvas> for Chromium.

CSS transforms #

Support for transform: perspective(none) is now supported in Chromium, Gecko and WebKit. This will make it easier to animate between a perspective and no perspective.

In Chromium, transform-style: preserve-3d (which allows child elements to participate in the same 3D scene) and the perspective property (which applies a perspective transform to child elements) are now aligned with the spec by making them apply only to child elements.

The big increase in the scores for CSS transforms for all browsers is mainly due to improvements to the test suite, where incorrect tests have been fixed or removed. This makes it easier to understand the remaining interoperability problems and avoid regressions in the future.

Conclusion #

We are grateful for the work that everyone has put in to end the year with many improvements to the score as well as better testing infrastructure. aspect-ratio was a long requested feature from web developers and it is now supported in all browsers. Use of flexbox, grid and position: sticky are all growing, and these features are now better supported across browsers thanks to many improvements made during 2021.

What's next? We are excited to continue collaborating with other browser vendors and the wider community in the next iteration of this effort. We have started to research and discuss the focus areas for 2022. Please look out for an announcement coming soon.

If you have any feedback or questions please reach out to us on Twitter at @ChromiumDev.

Compat 2021 mid-year update: Flex gap everywhere

2021-07-23T00:00:00Z

It's time for the mid-year update on Compat 2021—an effort to eliminate browser compatibility problems in five key focus areas. For more details about the #compat2021 work and how we decided on the areas of focus, check out the March announcement.

Improvements to Chromium discussed in this post will reach Chrome, Edge and all Chromium-based browsers.

How we measure progress #

You can check the Compat 2021 dashboard for web-platform-tests to see the number of passing tests and the trending graphs for different browsers.

A simple "passed tests" number doesn't tell the entire story of browser compatibility, however it is one of the signals we use to see the progress of our effort. Fewer differences between browsers in test results means greater interoperability of a web feature across multiple browsers.

A snapshot of Compat 2021 Dashboard (experimental browsers).

CSS flexbox #

All three browser engines saw improvements on flexbox.

Safari 14.1 shipped the gap property for flexbox . The gap property is a convenient way to set spacing between items. This property is often used in Grid layout, and support in flexbox layout was one of the most requested features in the MDN Browser Compatibility Report . With this update, the gap property in flex layouts is available in all major browsers and a top compatibility challenge is resolved. Safari 14.1 also included many fixes for images in flexbox, removing the need for old workarounds.

Firefox resolved rendering of tables as flex items, bumping Firefox closer to 100% passing tests (currently at 98.5%).

Chromium fixed tables as flex items as well. In Chromium 88, there was also a rewrite of images as flex items, resolving a number of long-standing bugs. Finally, Chromium recently added support for new alignment keywords : start, end, self-start, self-end, left, and right. These keywords are available to try in Chrome Canary and Edge Canary.

CSS Grid #

CSS Grid usage is growing steadily, currently at 9% of page views. All three major browser engines implement CSS Grid and are passing more than 89% of related web-platform-tests already. Closing the compatibility gap is important to support steady growth of this feature.

So far in 2021, Safari has improved from 89% to 93% passing tests, and Chromium is working on a new architecture to resolve more CSS Grid issues, called GridNG. This is an effort led by the Microsoft team, and led to the recent increase from 94% to 97% in the targeted Grid tests. You can expect an update on GridNG on the Edge blog soon.

CSS `position: sticky` #

In Chromium, position: sticky for table headers got fixed with the launch of TablesNG—a multi-year effort to re-architect rendering of tables. This change, together with a few final fixes, pushed the Chrome and Edge 93 developer channel to pass 100% of the targeted tests.

Beyond position: sticky, TablesNG resolved 72 Chromium bugs!

CSS `aspect-ratio` property #

The aspect-ratio property, which makes it straightforward to set width-to-height ratio, is crucial to responsive web design. It is also a solution to prevent cumulative layout shifts.

The aspect-ratio property is now supported in stable versions of Chrome, Edge, and Firefox, and in Safari 15 beta . As cross-browser support improves, usage is increasing.

Although no browser has 100% passing tests, the compatibility gap for aspect-ratio is the smallest of all five focus areas for Compat 2021. It has more than 90% passing tests for all major browsers . Moving forward, we'll keep monitoring the progress using this test suite to make it a rock-solid feature.

Learn more about the usage and benefits of the aspect-ratio property on web.dev.

CSS transforms #

There has been a slow and steady improvement in the results of the targeted tests for CSS transforms, due to both bug fixes, and improvements to the tests themselves.

The Chromium team is also working on improving the interoperability of transform-style: preserve-3d and transform :perspective(). We hope to have more progress to share in the next update.

Overall score improvements #

Since the announcement in March, all three browser engines have improved their Compat 2021 scores:

Chrome and Edge Dev went from 86 to 92.
Firefox went from 83 to 86.
Safari went from 64 to 82.

Notably, Safari has pushed to close the compatibility gap by 18 points, thanks to a lot of work from WebKit contributors. In particular the team at Igalia contributed to the aspect-ratio property and many improvements to Flexbox and Grid, such as gap for flexbox and various bug fixes.

Follow the Compat 2021 progress #

To follow the progress of Compat 2021, keep an eye on the dashboard, subscribe to our mailing list, or reach out to usat @chromiumdev. If you experience any issues make sure to file a bug for the affected browser.

Announcing Squoosh v2

2020-12-09T00:00:00Z

Squoosh is an image compression app our team built and debuted at Chrome Dev Summit 2018. We built it to make it easy to experiment with different image codecs, and to showcase the capabilities of the modern web.

Today, we are releasing a major update to the app with more codecs support, a new design, and a new way to use Squoosh on your command line called Squoosh CLI.

New codecs support #

We now support OxiPNG, MozJPEG, WebP, and AVIF, in addition to codecs natively supported in your browser. A new codec was made possible again with the use of WebAssembly. By compiling a codec encoder and decoder as WebAssembly module users can access and experiment with newer codecs even if their preferred browser does not support them.

Launching a command line Squoosh! #

Ever since the original launch in 2018, common user request was to interact with Squoosh programmatically without UI. We felt a bit conflicted about this path since our app was a UI on top of command-line-based codec tools. However we do understand the desire to interact with the whole package of codecs instead of multiple tools. Squoosh CLI does just that.

You can install the beta version of the Squoosh CLI by running npm i @squoosh/cli or run it directly using npx @squoosh/cli [parameters].

The Squoosh CLI is written in Node and makes use of the exact same WebAssembly modules the PWA uses. Through extensive use of workers, all images are decoded, processed and encoded in parallel. We also use Rollup to bundle everything into one JavaScript file to make sure installation via npx is quick and seamless. The CLI also offers auto compression, where it tries to reduce the quality of an image as much as possible without degrading the visual fidelity (using the Butteraugli metric).

With the Squoosh CLI you can compress the images in your web app to multiple formats and use the <picture> element to let the browser choose the best version. We also plan to build plugins for Webpack, Rollup, and other build tools to make image compression an automatic part of your build process.

Build process change from Webpack to Rollup #

The same team that built Squoosh has spent a significant amount of time looking at build tooling this year for Tooling Report, and decided to switch our build process from Webpack to Rollup.

The project was initially started with Webpack because we wanted to try it as a team, and at the time in 2018 Webpack was the only tool that gave us enough control to set up the project the way we wanted. Over time, we've found Rollup's easy plugin system and simplicity with ESM made it a natural choice for this project.

Updated UI design #

We've also updated the UI design of the app featuring blobs as a visual element. It is a little pun on how we treat data in our code. Squoosh passes image data around as a blob, so it felt natural to include some blobs in the design (get it?).

Color usage was honed in as well, so that color was more than an accent but additionally a vector to distinguish and reinforce which image is in context for the options. All in all, the homepage is a bit more vibrant and the tool itself is a bit more clear and concise.

What's next ? #

We plan to keep working on Squoosh. As the new image format gets released, we want our users to have a place where they can play with the codec without heavy lifting. We also hope to expand use of Squoosh CLI and integrate more into the build process of a web application.

Squoosh has always been open source but we've never had focus on growing the community. In 2021, we plan to expand our contributor base and have a better onboarding process to the project.

Do you have any ideas for Squoosh? Please let us know on our issue tracker. The team is headed to extended winter vacation but we promise to get back to you in the new year.

Introducing PROXX

2019-05-09T00:00:00Z

The team that brought you squoosh.app is back! This time, we built a web-based game called PROXX (proxx.app). PROXX is a game of proximity inspired by the legendary game Minesweeper. The game is situated in the space and your job is to find out where the black holes are. It works on all kinds of devices—from desktop all the way to feature phones. Users can play the game using a mouse, keyboard, d-pad even with a screen reader.

PROXX on a feature phone.

Our baseline #

Before building this game, we set the following goals and budgets for the application:

Same core experience: all devices must function the same way
Accessible: mouse, keyboard, touch, d-pad, screen readers
Performant:
- Less than 25kb of initial payload
- Less than 5 seconds TTI (time to interactive) on slow 3G
- Consistent 60fps animation

PROXX on a pixelbook.

Web Workers #

The game consists of 4 main entities, the core game logic, the UI service, the state service, and the animation graphics. Since we knew from the get-go we would have to run heavily animated graphics on the main thread, we moved the game logic and state service to a web worker in order to keep the main thread as free as possible.

Build time pre-render #

Our UI is built with Preact, as it allows us to hit our aggressive target for an initial payload that is less than 25kb. In order to give a good initial loading experience, we decided to pre-render our 1st view. We prerender at build time using Puppeteer to access the top page and let preact populate the DOM. The resulting DOM is then serialized to HTML and saved as index.html

Canvas for animation, (invisible) DOM For accessibility #

We render the game graphics in a canvas using WebGL. One canvas is responsible for the background animation and another one canvas for the game grid on top. We also have an HTML table with buttons for accessibility reasons, that is on top of both of these canvases, but is made invisible (opacity: 0). Even though what you see is a canvas rendering of the game state, the player is interacting with the invisible DOM table, giving us the ability to attach event listeners and rely on the browser's focus management.

By keeping the DOM element in the canvas, we are able to tap into browsers built-in accessibility features. For example: by setting role="grid" on our game table, screen readers can announce the row and column of the focused cell without us having to implement that.

Rollup for bundling and code splitting #

Our total size for the app comes down to 100KB gzipped. Out of that, 20KB is for the initial payload (index.html). We use Rollup.js for this project. We have shared dependencies between the main thread and our web worker, and Rollup can put these shared dependencies in a separate chunk that only needs to be loaded once. Other bundlers like webpack duplicate the shared dependencies which results in double-loading.

Supporting feature phones #

Smart feature phones such as KaiOS phones are rapidly gaining popularity. These are very resource constrained devices, but our approach of using web workers whenever we can allowed us to make the experience highly responsive on these phones as well. Since feature phones come with different input interface (d-pad and number keys, no touchscreen), we also implemented key-based interface.

PROXX on a feature phone.

What's next #

We had great but busy time building this game in time for Google I/O 2019, so we will take some well-deserved time off to rest, but plan to come back with more in-depth documentation on each of these areas of the game.

Until then, please check the talk Mariko gave at I/O on this project.

You can browse the code at the proxx github repo.

Cheers! Surma, Jake, Mariko

Same-origin policy

2018-11-05T00:00:00Z

The same-origin policy is a browser security feature that restricts how documents and scripts on one origin can interact with resources on another origin.

A browser can load and display resources from multiple sites at once. You might have multiple tabs open at the same time, or a site could embed multiple iframes from different sites. If there is no restriction on interactions between these resources, and a script is compromised by an attacker, the script could expose everything in a user's browser.

The same-origin policy prevents this from happening by blocking read access to resources loaded from a different origin. "But wait," you say, "I load images and scripts from other origins all the time." Browsers allow a few tags to embed resources from a different origin. This policy is mostly a historical artifact and can expose your site to vulnerabilities such as clickjacking using iframes. You can restrict cross-origin reading of these tags using a Content Security Policy.

What's considered same-origin? #

An origin is defined by the scheme (also known as the protocol, for example HTTP or HTTPS), port (if it is specified), and host. When all three are the same for two URLs, they are considered same-origin. For example, http://www.example.com/foo is the same origin as http://www.example.com/bar but not https://www.example.com/bar because the scheme is different.

What is permitted and what is blocked? #

Generally, embedding a cross-origin resource is permitted, while reading a cross-origin resource is blocked.

iframes	Cross-origin embedding is usually permitted (depending on the `X-Frame-Options` directive), but cross-origin reading (such as using JavaScript to access a document in an iframe) isn't.
CSS	Cross-origin CSS can be embedded using a `<link>` element or an `@import` in a CSS file. The correct `Content-Type` header may be required.
forms	Cross-origin URLs can be used as the `action` attribute value of form elements. A web application can write form data to a cross-origin destination.
images	Embedding cross-origin images is permitted. However, reading cross-origin image data (such as retrieving binary data from a cross-origin image using JavaScript) is blocked.
multimedia	Cross-origin video and audio can be embedded using `<video>` and `<audio>` elements.
script	Cross-origin scripts can be embedded; however, access to certain APIs (such as cross-origin fetch requests) might be blocked.

Check whether specified actions in cross-origin resources are allowed

A webpage on the web.dev domain includes this iframe:

<iframe id="iframe" src="https://example.com/some-page.html" alt="Sample iframe"></iframe>

The webpage's JavaScript includes this code to get the text content from an element in the embedded page:

const iframe = document.getElementById('iframe');
const message = iframe.contentDocument.getElementById('message').innerText;

Is this JavaScript allowed?

No. Since the iframe is not on the same origin as the host webpage, the browser doesn't allow reading of the embedded page.

A webpage on the web.dev domain includes this form:

<form action="https://example.com/results.json">
  <label for="email">Enter your email: </label>
  <input type="email" name="email" id="email" required>
  <button type="submit">Subscribe</button>
</form>

Can this form be submitted?

Yes. Form data can be written to a cross-origin URL specified in the action attribute of the <form> element.

A webpage on the web.dev domain includes this iframe:

<iframe src="https://example.com/some-page.html" alt="Sample iframe"></iframe>

Is this iframe embed allowed?

Usually. Cross-origin iframe embeds are allowed as long as the origin owner hasn't set the X-Frame-Options HTTP header to deny or sameorigin.

A webpage on the web.dev domain includes this canvas:

<canvas id="bargraph"></canvas>

The webpage's JavaScript includes this code to draw an image on the canvas:

var context = document.getElementById('bargraph').getContext('2d');
var img = new Image();
  img.onload = function() {
  context.drawImage(img, 0, 0);
};
img.src = 'https://example.com/graph-axes.svg';

Can this image be drawn on the canvas?

Yes. Although the image is on a different origin, loading it as an img source does not require CORS. However, accessing the binary of the image using JavaScript such as getImageData, toBlob or toDataURL requires an explicit permission by CORS.

How to prevent Clickjacking #

Figure: Clickjacking mechanism illustrated in 3 separate layers (base site, iframed site, transparent button).

An attack called "clickjacking" embeds a site in an iframe and overlays transparent buttons which link to a different destination. Users are tricked into thinking they are accessing your application while sending data to attackers.

To block other sites from embedding your site in an iframe, add a content security policy with frame-ancestors directive to the HTTP headers.

Alternatively, you can add X-Frame-Options to the HTTP headers see MDN for list of options.

Wrap up #

Hopefully you feel a little relieved that browsers work hard to be a gatekeeper of security on the web. Even though browsers try to be safe by blocking access to resources, sometimes you want to access cross-origin resources in your applications. In the next guide, learn about Cross-Origin Resource Sharing (CORS) and how to tell the browser that loading of cross-origin resources is allowed from trusted sources.

Browser sandbox

2018-11-05T00:00:00Z

To defend against attacks, a developer needs to mitigate vulnerabilities and add security features to an application. Luckily, on the web, the browser provides many security features. Some are available for developers to opt-in, and some are turned on by default to protect users.

The idea of a "sandbox" #

Figure: Browser as a sandbox

Modern web browsers are built on the idea of a "sandbox". A sandbox is a security mechanism used to run an application in a restricted environment. Just like the physical sandbox at a playground where kids can create anything they want within the boundary without making a mess elsewhere, application code has the freedom to execute within a restricted environment. For example, JavaScript can add and modify elements on the page but might be restricted from accessing an external JSON file. This is because of a sandbox feature called same-origin

Why is a sandbox necessary? #

Every day, users of the web download arbitrary code and execute it on their computer or phone multiple times. If someone told you "Hey! Download and run this application!", you might pause to think if that application comes from a trusted source, read up on the application vendor, or check reviews carefully. How about when someone sends you a URL saying "check out this blog post"? You would probably click on it without asking questions like "What kind of JavaScript will this site download?".

The browser sandbox is the key feature that makes browsing on the web frictionless by making it safer to run arbitrary code.

Make it secure by design #

If the browser is sandboxing each web application, should we even care about security? Absolutely yes!

First of all, sandbox features are not the perfect shield. Even though browser engineers work hard, browsers could have vulnerabilities and attackers are always trying to bypass the sandbox (such as with Spectre Attack).

The sandbox could sometimes get in a way of creating a great web experience. For example, a browser may block a fetch request to an image hosted on a different domain. You can share resources on different domains by turning on Cross-Origin Resource Sharing (CORS for short), but if it is not done carefully you can expose a resource to everyone else on the web, essentially undoing the sandbox.

Wrap up #

A secure web experience can only be achieved if security is baked into the design of your application, and strong design starts with understanding existing features. The next two guides dive into CORS and same-origin policy in depth.

Same Origin Policy & Fetch requests

2018-11-05T00:00:00Z

In this codelab, see how the same-origin works when fetching resources.

Set up: Fetch page from same origin #

The demo is hosted at https://same-origin-policy-fetch.glitch.me. This simple web page uses fetch to load resource from https://same-origin-policy-fetch.glitch.me/fetch.html. Since index.html and fetch.html share the same origin, you should see 200 displayed on the live preview.

1. Fetch page from different origin #

Try to change the fetch URL to https://www.google.com. What do you see in the live preview?

The browser should have blocked the fetch request because you requested a resource from a different origin. This means an attacker cannot read cross-origin resources even if they have taken control of a user's browser.

2. Fetch a cross-origin resource #

Try changing the fetch URL to https://api.thecatapi.com/v1/images/search. What do you see in the live preview?

The fetch URL is a different origin, but you should see the status code 200. Why? Modern web applications often request cross-origin resources to load third-party scripts or query an API endpoint. To accommodate these use cases, there is a mechanism called CORS (Cross Origin Resource Sharing) to tell the browser that loading of a cross-origin resource is allowed. See Share cross-origin resources safely for more on CORS.

Same Origin Policy & iframe

2018-11-05T00:00:00Z

In this codelab, see how the same-origin policy works when accessing data inside an iframe.

Set up: Page with a same-origin iframe #

This page embeds an iframe, called iframe.html, in the same origin. Since the host and the iframe share the same origin, the host site is able to access data inside of the iframe and expose the secret message like blow.

const iframe = document.getElementById('iframe');
const message = iframe.contentDocument.getElementById('message').innerText;

Change to cross-origin iframe #

Try changing the src of the iframe to https://other-iframe.glitch.me/. Can the host page still access the secret message?

Since the host and embedded iframe do not have the same origin, access to the data is restricted.

Cross-Origin Resource Sharing (CORS)

2018-11-05T00:00:00Z

The browser's same-origin policy blocks reading a resource from a different origin. This mechanism stops a malicious site from reading another site's data, but it also prevents legitimate uses. What if you wanted to get weather data from another country?

In a modern web application, an application often wants to get resources from a different origin. For example, you want to retrieve JSON data from a different domain or load images from another site into a <canvas> element.

In other words, there are public resources that should be available for anyone to read, but the same-origin policy blocks that. Developers have used work-arounds such as JSONP, but Cross-Origin Resource Sharing (CORS) fixes this in a standard way.

Enabling CORS lets the server tell the browser it's permitted to use an additional origin.

How does a resource request work on the web? #

Figure: Illustrated client request and server response

A browser and a server can exchange data over the network using the Hypertext Transfer Protocol (HTTP). HTTP defines the communication rules between the requester and the responder, including what information is needed to get a resource.

The HTTP header is used to negotiate the type of message exchange between the client and the server and is used to determine access. Both the browser's request and the server's response message are divided into two parts: header and body:

Information about the message such as the type of message or the encoding of the message. A header can include a variety of information expressed as key-value pairs. The request header and response header contain different information.

Sample Request header

Accept: text/html
Cookie: Version=1

The above is equivalent to saying "I want to receive HTML in response. Here is a cookie I have."

Sample Response header

Content-Encoding: gzip
Cache-Control: no-store

The above is equivalent to saying "Data is encoded with gzip. Do not cache this please."

body #

The message itself. This could be plain text, an image binary, JSON, HTML, and so on.

How does CORS work? #

Remember, the same-origin policy tells the browser to block cross-origin requests. When you want to get a public resource from a different origin, the resource-providing server needs to tell the browser "This origin where the request is coming from can access my resource". The browser remembers that and allows cross-origin resource sharing.

Step 1: client (browser) request #

When the browser is making a cross-origin request, the browser adds an Origin header with the current origin (scheme, host, and port).

Step 2: server response #

On the server side, when a server sees this header, and wants to allow access, it needs to add an Access-Control-Allow-Origin header to the response specifying the requesting origin (or * to allow any origin.)

Step 3: browser receives response #

When the browser sees this response with an appropriate Access-Control-Allow-Origin header, the browser allows the response data to be shared with the client site.

See CORS in action #

Here is a tiny web server using Express.

The first endpoint (line 8) does not have any response header set, it just sends a file in response.

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Console tab.
Try the following command:

fetch('https://cors-demo.glitch.me/', {mode:'cors'})

You should see an error saying:

request has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header
is present on the requested resource.

The second endpoint (line 13) sends the same file in response but adds Access-Control-Allow-Origin: * in the header. From the console, try

fetch('https://cors-demo.glitch.me/allow-cors', {mode:'cors'})

This time, your request should not be blocked.

For privacy reasons, CORS is normally used for "anonymous requests"—ones where the request doesn't identify the requestor. If you want to send cookies when using CORS (which could identify the sender), you need to add additional headers to the request and response.

Request #

Add credentials: 'include' to the fetch options like below. This will include the cookie with the request.

fetch('https://example.com', {
  mode: 'cors',
  credentials: 'include'
})

Response #

Access-Control-Allow-Origin must be set to a specific origin (no wildcard using *) and must set Access-Control-Allow-Credentials to true.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Preflight requests for complex HTTP calls #

If a web app needs a complex HTTP request, the browser adds a preflight request to the front of the request chain.

The CORS specification defines a complex request as

A request that uses methods other than GET, POST, or HEAD
A request that includes headers other than Accept, Accept-Language or Content-Language
A request that has a Content-Type header other than application/x-www-form-urlencoded, multipart/form-data, or text/plain

Browsers create a preflight request if it is needed. It's an OPTIONS request like below and is sent before the actual request message.

OPTIONS /data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: DELETE

On the server side, an application needs to respond to the preflight request with information about the methods the application accepts from this origin.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

The server response can also include an Access-Control-Max-Age header to specify the duration (in seconds) to cache preflight results so the client does not need to make a preflight request every time it sends a complex request.

What are security attacks?

2018-11-05T00:00:00Z

An insecure application could expose users and systems to various types of damage. When a malicious party uses vulnerabilities or lack of security features to their advantage to cause damage, it is called an attack. We'll take a look at different types of attacks in this guide so you know what to look for when securing your application.

Active attacks vs passive attacks #

Attacks can be divided into two different types: active and passive.

Active attacks #

With an active attack, the attacker tries to break into the application directly. There are a variety of ways this could be done, from using a false identity to access sensitive data (masquerade attack) to flooding your server with massive amounts of traffic to make your application unresponsive (denial of service attack).

Active attacks can also be done to data in transit. An attacker could modify your application data before it gets to a user's browser, showing modified information on the site or direct the user to an unintended destination. This is sometimes called modification of messages.

A web site being tampered by attacker to guide user to a phishing site.

Passive attack #

With a passive attack, the attacker tries to collect or learn information from the application but does not affect the application itself.

Attacker eavesdropping communication between a user and a server.

Imagine someone is eavesdropping on your conversation with friends and family, collecting information about your personal life, who your friends are, and where you hang out. The same thing could be done on your web traffic. An attacker could capture data between the browser and the server collecting usernames & passwords, users' browsing history, and data exchanged.

Defense against attacks #

Attackers can directly harm your application or perform a malicious operation on your site without you or your users noticing it. You need mechanisms to detect and protect against attacks.

Unfortunately, there is no single solution to make your application 100% secure. In practice, many security features and techniques are used in layers to prevent or further delay the attack (this is called defense in depth). If your application contains a form, you might check inputs in the browser, then on the server, and finally at the database; you would also use HTTPS to secure the data in transit.

Wrap up #

Since many attacks can happen without ever hitting your server, it is sometimes hard to detect if attacks are happening or not. The good news is that web browsers have powerful security features already built in. Follow the next topic "How browser mitigates against attacks" to learn more.

Security should not be so scary!

2018-11-05T00:00:00Z

What do you imagine when someone says "security"?

Hackers? Attacks? Defenses? A programmer in a black hoodie in a dark room?

When the word "security" comes to mind, it's usually in the context of bad news. You often encounter headlines like "A big social network leaked login passwords" or "an attacker stole credit card information from a shopping site".

But security is something to be taken as a positive and necessary part of web development just like "user experience" or "accessibility".

A hacker in hoodie is a negative security image. A team working on a project together is a positive security image.

In the next few guides, you'll learn how to keep your business and your users' content secure.

What is a security vulnerability? #

In software development, when an application does not work the way it is intended to work, it's called "a bug". Sometimes a bug displays wrong information or crashes on a certain action. A vulnerability (sometimes called a security bug) is a type of bug that could be used for abuse.

Bugs are common in the day to day activities of a developer. Which means, vulnerabilities are also frequently introduced into applications. What's important is that you are aware of common vulnerabilities in order to mitigate them as much as you can. It is just like minimizing other bugs by following common patterns and techniques.

Most security techniques are just good programming, for example:

Check values entered by a user (not null, not an empty string, checking the amount of data).
Ensure a single user can't take up too much time.
Build unit tests so security bugs can't slip in by accident.

What are security features? #

Your first lines of defense are security features such as HTTPS and CORS. (You'll learn about these acronyms later so don't worry about them for now.) For example, encrypting data using HTTPS might not be fixing a bug, but it protects the data you're exchanging with users to other parties. (Intercepting data is a common attack.)

What's the impact? #

When an application is not secure, different people could be affected.

Impact on users	Sensitive information, such as personal data, could be leaked or stolen. Content could be tampered with. A tampered site could direct users to a malicious site.
Impact on the application	User trust may be lost. Business could be lost due to downtime or loss of confidence as a result of tampering or system shortage.
Impact on other systems	A hijacked application could be used to attack other systems, such as with a denial-of-service attack using a botnet.

Actively securing your application is not only crucial for you and your business but also for your users, protecting them and other systems from attacks launched from your site.

Wrap up #

Congratulations! You are halfway through this introduction. Now you know the difference between security vulnerabilities and features, and you are aware that not only you but everyone else gets affected when your application is not secure. The next guide covers the types of attacks in depth to make security even less scary.

Mariko Kosaka on web.dev

Baseline features you can use today

The dialog element #

Individual CSS transform properties #

New viewport units #

Deep copy in JavaScript #

The :focus-visible pseudo-class #

The TransformStream interface #

Wrap up #

Compat 2021 Holiday Update: presents for developers before the end of the year

CSS flexbox #

CSS Grid #

CSS position: sticky #

CSS aspect-ratio property #

CSS transforms #

Conclusion #

Compat 2021 mid-year update: Flex gap everywhere

How we measure progress #

CSS flexbox #

CSS Grid #

CSS position: sticky #

CSS aspect-ratio property #

CSS transforms #

Overall score improvements #

Follow the Compat 2021 progress #

Announcing Squoosh v2

New codecs support #

Launching a command line Squoosh! #

Build process change from Webpack to Rollup #

Updated UI design #

What's next ? #

Introducing PROXX

Our baseline #

Web Workers #

Build time pre-render #

Canvas for animation, (invisible) DOM For accessibility #

Rollup for bundling and code splitting #

Supporting feature phones #

What's next #

Same-origin policy

What's considered same-origin? #

What is permitted and what is blocked? #

How to prevent Clickjacking #

Wrap up #

Browser sandbox

The idea of a "sandbox" #

Why is a sandbox necessary? #

Make it secure by design #

Wrap up #

Same Origin Policy & Fetch requests

Set up: Fetch page from same origin #

1. Fetch page from different origin #

2. Fetch a cross-origin resource #

Same Origin Policy & iframe

Set up: Page with a same-origin iframe #

Change to cross-origin iframe #

Cross-Origin Resource Sharing (CORS)

How does a resource request work on the web? #

header #

body #

How does CORS work? #

Step 1: client (browser) request #

Step 2: server response #

Step 3: browser receives response #

See CORS in action #

Share credentials with CORS #

Request #

Response #

Preflight requests for complex HTTP calls #

What are security attacks?

Active attacks vs passive attacks #

Active attacks #

Passive attack #

Defense against attacks #

Wrap up #

Security should not be so scary!

What is a security vulnerability? #

What are security features? #

What's the impact? #

Wrap up #

The `:focus-visible` pseudo-class #

CSS `position: sticky` #

CSS `aspect-ratio` property #

CSS `position: sticky` #

CSS `aspect-ratio` property #