Name: HTTP headers for the responsible developer by Stefan Judis | JSConf EU 2019
Uploaded: 2020-03-28T16:10:08.000Z
Duration: 23 min 21 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Hello? Hello, everybody. How is the day going? HTTP  we have to do that again. How is the day going? HTTP headers for the responsible developer. Let me tell you about my journey

on the web. I was one of these lucky people that had an Internet connection at home very

Adverbs of manner

early because my father was a techsavvy person. But in the beginning, I had no idea what to

do with the Internet, I could Google or surf, that was it. I was whatever, 12 years old

and it was not that exciting. But then I discovered this website, woot.com. Any Germans around?

That was one of the first social networks in Germany. And there I was, 1999. This is

where I'm coming from, the middle of nowhere in Germany. And I found myself chatting to

people if Berlin. Mainly about music. This is when I found out for the first time that

the web actually connects people. It's not about Googling stuff, it's about connecting

people. Then I moved to Berlin and I had a different

job initially. In 2010 something interesting happened, I became a web developer. Which

was cool. But then the statement that the web connects people actually changed. We as

developers have a lot of power. And I 100% believe that we connect people. Because we

are building stuff for the Internet. We enable people. And we help people by the

stuff that we build. So, let me quickly introduce myself. Hey, I'm Stefan. I work for a company

called Twilio. We do communications as an API, S MS and phone calls, and check that

out. And the most important thing is, hey, I'm Stefan, and I want to be a responsible

developer. So, when we look at the global population,

you will find out that 1999, there I was in my little bubble north of Germany. Not much

going on. But where actually the most Internet users are coming from today? So, they're coming

from China, India and the United States. But this is just global statistics, right? But

I also do run a private blog. And only the last month I had 300 people from Brazil reading

articles. I had 100 people from Vietnam. And I had 80 people from South Africa. That gets

me really excited, right? Who am I? I'm writing stuff and people in Brazil are reading my

stuff. But in the end that really doesn't matter because we as web developers should

be building for everybody. And when responsive web design came up, I heard this sometime

way too often. We don't have users coming from a certain area. We don't have users that

use a certain device. When you say these kinds of statements, you're creating a chicken and

egg problem. When you don't build stuff that works for people under certain conditions,

these people won't use your stuff. But building a good website these days is

actually very, very hard. What do you have to do? You have to consider design. Colors

around the world are different. You have to bring up good content. You have to consider

web performance which is a big topic by itself. You have to make yourself accessible because

there maybe people that visit your sites with assistive technology. And you have to find,

what should I use, actually? Frameworks are a thing. You have to optimize the network

stack and you have to make it work on several devices. And there are many, many more factors

out there. And in the next 21 minutes I want to talk about the network stack. So, let's

talk about HTTP. So, basically when your browser makes a requests

for a resource, what it does, sends value pairs, these are called request headers. And

the server responds with another set of key value pairs and the actual resource that you're

asking for. So, we're dealing with responsive request headers.

And when I started preparation for this talk, it was trending, so I had to buy a dot Dev

domain. You can see the responsible dot div and the site, but it right now has JavaScript

disabled. You see when I refresh it, there is some stuff going on. First of all, the

script is hijacking, adding unicorns and stuff. But going to this, you can pretend to be my

site. You can track what I'm doing, pretending to be my unicorn, not responsible unicorn,

but my Dev site. I wanted to make it better just using headers.

And the web is scary place. A few months ago, this was in the news. Lots of websites were

mining cryptocurrency and the developers that built these sites didn't even know about this.

And the reason for that is when we're building for the web, we're relying on other people

building software. Open source is the thing and we're also thirdparties from different

domains. So, we always rely on others and our belief that the web has to be safe. The

biggest part of being safe is HTTPS. So, without HTTPS, what is possible is that

someone can Open up a public WiFi and you're browsing with HTTP, this person could pretend

to be the WiFi and get the requests and mess with you. Or get the passports that you're

sending over HTTP. HTTPS lets you use HTTP/2 and service workers and media. And in my bubble,

I think it's the standard. But there's a site out there called why no HTTPS and it is many,

many sites not enforcing HTTPS yet. When you go into the list, you find out that there's

a massive German media outlet not enforcing HTTPS which is surprising.

When you run on HTTPS, you want to ensure that it is always HTTPS and on a secure connection.

So, what you can do is you can set the strict transport security header which you can define

a max H property in seconds. This will tell the browser, hey, please only use this website

or these resources over HTTPS. You can define how wide it should range. And you can, if

you want to go the extra mile, you can define a preload director which basically allows

you to supplement your site to another site, which is called HTTPS preload. And the thing

about that is that browsers internally keep lists of websites that should only be on HTTPS.

This is the configuration profile in Chromium. It's thousands of sites that will never work

on HTTP. If you wonder why dot Dev domains are not over HTTP anymore, that's the reason.

They're in this file. But HTTPS is not only about security. What happens when you type

in the address of the browser? It the make an HTTPS request and could lead to a delay

of 35 seconds depending on the connection. And you can skip this request because the

browser knows we're going HTTPS. That's it. So, how is the support for HTTPS? We're pretty

green here. Pretty sweet. But enforcing HTTPS is not the easiest thing in the world when

dealing with big projects when a lot of people are putting a lot of source code in your codebase.

How do you tackle this approach to go over HTTPS? When you run your site over HTTPS and

you make a request to an HTTP, it may be blocked by the browser. You can set a content security

header with the directive and this magically updates all the requests to be HTTPS and secure.

That is supercool. But this is not the main purpose of CSP. The main purpose of CSP is

that you want to limit what is allowed inside of your websites. And you can configure a

lot of things. So, this is the complete list of what is possible

with CSP. You can define where should fonts be loaded from, where should images be loaded

from. And a few cutting-edge things in there like this opener. Navigate too. And you can

basically trim down what is allowed in your website and you can avoid mining cryptocurrency

in your website because a thirdparty got hacked. You can use CSP with a meta element in your

HTML or you set a header like this. This is the head their I ship for my private

website. And includes all the thirdparties that I have. And coming up with this is actually

very, very hard. I deployed CSP three times and broke my site and rolled back. So, what

you want to do is you want to set a different header which is report only which then allows

you to define an HTTP end point and then you get all the warnings of requests that would

be blocked if this would be active. And you can start monitoring what is going on.

When you watch this  when you have a detailed look at this, you will find out there is something

not right. I have unsafe in line and unsafe evil right there and it bothers me. But I'm

using a JavaScript a that inlines JavaScript JSON in the body so that the JavaScript framework

end gets the state. And I'm working on fixing that. It's not the easiest when dealing with

a framework. The way this should work is that inline scripts, when you have CSP enabled,

you have two ways You can either define a hashed value in your

CSP directive so that you can say, hey, this hashed value should be allowed in my website.

This is a little bit brittle, though, because now when you update your contents of the script,

then you have to change this header or your meta element in the edge. What you can do

is you can define a nonce value. Giving an ID and say, hey, this part is cool. Please

Subtitles ListPlay Video

HTTP headers for the responsible developer by Stefan Judis | JSConf EU 2019

stuff

massive

process

content