free wifi
💾 Programlama

Web Frontend Security: Episode 1

In this post series, I’ll explain some of the most common attack methods used on web frontend and how to take precautions to prevent them. It contains an overview of frontend security related things that every web developer needs to know by heart. I will explain terms like XSS, CSRF, clickjacking, CSP, HSTS, JWT, HTTP-Only Cookies.

In this particular post, I’ll focus on the security issues that are caused by improperly established secure transport. So let’s get started!

What is a “web frontend” and why security awareness is essential


A frontend is the “customer facing” end of a product where the customer might be mass consumers or a department in a company or one single person. “Web Frontend” is a frontend product that is exposed in a web interface. Other frontends could be a mobile application, a public API and so on…

A secure product must make sure that everyone can see what they should’ve seen and execute commands that only they are allowed to. Security must always be an ongoing progress across the whole product. You can’t add “security” later, you have to bake it in.

Web Frontend, being a part of a larger product also needs to be secure. It needs to be implemented in a way where it doesn’t leak users’ data to others or execute not requested commands.

In my belief, every engineer across an organization has to be educated against common attack methods. “Being awake against misuses” should be a cultural thing in engineering teams.

Okay, I admit: This section was a little bit academic, I promise that the upcoming section is more exciting. %-)

Attacks caused by lack of properly established secure transport

Security is an end-to-end task. You need to be sure that your frontend communicates to the backend using a secure channel.



HTTPS is a secure transport protocol, where the contents of a request and response are encrypted end-to-end between the client (your frontend) and the host (your backend). In this post, I won’t explain the details of how it works. I’ll try to “go around” of it.

When a user types a web address starting with https:// the communication is done securely.

But what if I just type the site name?

The thing is people don’t always type the full address. It is common to type instead of And there are a large number of websites still serve their content on both http and https, both unsecured and secured connection work in parallel. We have a vulnerability over here!

Redirecting http to https

A naive approach to overcome this vulnerability is to redirect http pages to their https equivalents via HTTP 301 Moved Permanently. This way, if someone ends up with http, they will be “upgraded”.

Imagine that at some point you had logged into the website at and checked “remember me”. They issued you a cookie named token which expires in one month and helps them identify you.

At an airport, you tried to reach on your machine and sent a request like this:

GET / HTTP/1.1

and redirected you to “secure” protocol, https:

HTTP/1.1 301 Moved Permanently

In your second request, you reached to making the communication secure.

Don’t forget to take that free unsecured airport Wifi into account…

When you reached you were at the airport, connected to the free-wifi. So does the guy next to you: Listening to all network packages in the wifi network, intercepting and reading all contents of the web pages transferred via http. Although you “upgraded” to https in your very second request, the first and insecure request contained token=SECRET_HASH_THAT_IDENTIFIES_USER and it is served in a golden plate to the guy that listens to the traffic. Now, he can use this token and to access to logged in as you… ????

Secure Cookies

secure cookie

A solution to overcome “unsecured credential transfer” would be to send cookies only when the connection is secure. In this scenario, sends a Secure cookie, so it won’t be sent unless the connection is over HTTPS.

At the airport when you reach this time, your request will not include sensitive credentials:

GET / HTTP/1.1

and you’ll be upgraded to https version:

HTTP/1.1 301 Moved Permanently

where you start sending cookie this time, as it is secure:

GET / HTTP/1.1

Looks secure. The guy that listens to the network won’t be able to steal your cookie.


HTTP responses can be altered

In an insecure network, a man in the middle can intercept and return a tampered, modified version of the response back to you. In our scenario, let’s assume that the guy that listens to the network tampers with the http responses and returns whatever he wants to return back.

In this scenario when you reach, instead of getting the genuine response back (which is a redirect), you get the response back from “the guy that listens”:

HTTP/1.1 200 OK

He sent you a well prepared, genuine looking web page, where he asked for your username, password. You typed them and sent them directly to the attacker. You never got the upgrade to HTTPS and you didn’t even notice it… Don’t forget:

Even a single insecure request can be enough to steal the data!

HTTP Strict Transport Security (HSTS)

HSTS is an HTTP header which tries to overcome the problem explained above. By sending an HSTS header over a secure connection, you can tell the browser that you always expect a secure connection and tell the browser to upgrade automatically from now on, even if user types http:// explicitly.

In our scenario, as we had logged in beforehand, we at least reached to before heading to the airport once. At that moment, sent the following header to us:

Strict-Transport-Security: max-age=<expire-time>; includeSubDomains

Thanks to this header, the browser is aware of security precautions. At the airport, when the user tries to reach browser upgraded it to https automatically. The guy that listens to the network didn’t have a chance to intercept as no insecure communication done.

Still, the first request is not secured…

HSTS helps us a great deal mitigating man in the middle attacks. However, HSTS header needs to served once over HTTPS to be effective. If we reach for the first time at the airport, a man-in-the-middle attack is still possible as HSTS header is not effective yet.

HSTS Preloading

Google maintains an HSTS preload service which is used by all major browsers. The list contains websites that need to be reached via HTTPS only. By taking advantage of the list browsers remove need to receive HSTS header from the website itself. Therefore, even for the first reach to communication can be upgraded to due to the implicit knowledge of the browser about the HSTS requirement of the This eliminates man in the middle attack, even for the first reach. However, HSTS preloading is not part of the HSTS specification so it is not a standard.

You can check if your website is HSTS Preload enabled and apply for it on this website.

Wrapping Up – Recommendations

  • Know what you are doing.
  • Keep reading about HTTP, HTTPS and other protocols that the Internet mostly relies on.
  • Assume the worst and be prepared for man in the middle attacks.
  • Be sure that all data transport is encrypted. If you transfer the data from end-user to CDN via HTTPS and from CDN to the backend via HTTP it will only look secure.
  • Educate employees about security and work with people that care about security.
  • Don’t try to add security later. It should be built-in.
  • Don’t let urgency to deliver new features beat the urge to think and design security!

Up next

In next part, I plan to mention about CSRF. Stay tuned!

👋 🚨 Yeni yazılardan haberdar olmak ister misiniz? 👇

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir