# Clerk Blog — Page 15

# How HttpOnly cookies help mitigate XSS attacks
URL: https://clerk.com/blog/how-httponly-cookies-help-mitigate-xss-attacks.md
Date: 2021-05-06
Category: Engineering
Description: HttpOnly cookies do not prevent cross-site scripting (XSS) attacks, but they do lessen the impact and prevent the need to sign out users after the XSS is patched. HttpOnly cookies are not a substitute for XSS prevention measures.

**In short: HttpOnly cookies do not prevent [cross-site scripting (XSS)](https://owasp.org/www-community/attacks/xss) attacks, but they do lessen the impact and prevent the need to sign out users after the XSS is patched. HttpOnly cookies are not a substitute for XSS prevention measures.**

Our very first architecture decision at Clerk was to use HttpOnly cookies for session management. It has long been understood that HttpOnly cookies help mitigate cross-site scripting (XSS) attacks, and we felt it was important to include this best-practice directly in our product.

But while there's strong consensus that using HttpOnly cookies is a best practice, we've found many developers are unsure of how they help with XSS. We think this stems from the guidance, which often just says what to do rather than explaining why:

> A cookie with the HttpOnly attribute is inaccessible to the JavaScript[ Document.cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie) API; it is sent only to the server. For example, cookies that persist server-side sessions don't need to be available to JavaScript, and should have the HttpOnly attribute. This precaution helps mitigate cross-site scripting ([XSS](https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#cross-site_scripting_\(xss\))) attacks.\
> [Mozilla MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies)

> Cookies \[...] SHOULD be tagged to be inaccessible via JavaScript (HttpOnly).\
> [NIST 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html#711-browser-cookies)

## The attack vector

After reading this guidance, you might be surprised to learn that HttpOnly cookies do not prevent XSS attacks.

Instead, HttpOnly cookies are helpful when you assume an XSS attack will happen and want to **lessen the impact**. Ultimately, they mitigate XSS attacks by making it easier for organizations to respond.

The specific threat HttpOnly cookies protect against is called **session token exfiltration**, which is a fancy way of saying that the attacker is able to steal a user's session token.

When a session token is stored in a cookie *without* the HttpOnly flag, the token can be stolen during an XSS attack with [document.cookie](https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie). This is problematic because session tokens are the primary mechanism used by backends to authenticate a user.

**Once an attacker has access to a session token, they can often act on behalf of a user until that token expires or is revoked.** Actions can be taken remotely - even if the user is no longer visiting the page with the XSS vulnerability - which can serve to dramatically increase the surface area of the attack.

Conversely, when a session token is stored in a cookie *with* the HttpOnly flag, that token cannot be directly exfiltrated during an XSS attack. This minimizes the surface area of the XSS attack and makes it easier for organizations to respond.

## Responding to XSS attacks - without HttpOnly cookies

When an organization is responding to an XSS attack, the first step is always patching the XSS vulnerability.

If HttpOnly cookies were not used, organizations should then assume that session tokens were exfiltrated. This means that - even with the XSS vulnerability patched - the attacker may still have the ability to act on behalf of users.

The next step is revoking the session of any user who may have been subjected to the XSS vulnerability, since those are the users who may have had their session tokens exfiltrated. These users will need to sign in again next time they visit the website.

Lastly, the organization will need to reverse any actions the attacker took on behalf of their users, from the time the vulnerability began to the time session tokens were revoked.

## Responding to XSS attacks - with HttpOnly cookies

With HttpOnly cookies, organizations still need to patch the XSS vulnerability and reverse any actions taken on behalf of their users, but they do not need to revoke sessions and ask users to sign in again.

## What about localStorage and sessionStorage?

Although [window.localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage) and [window.sessionStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage) are newer client-side storage APIs, they function like cookies *without* the HttpOnly flag. HttpOnly cookies are still the only standard mechanism for persisting session tokens that cannot be exfiltrated during an XSS attack.

---

# How to deploy Clerk using Vercel with one click
URL: https://clerk.com/blog/clerk-vercel-one-click-deployment.md
Date: 2021-04-11
Category: Guides
Description: If you are looking to implement Auth in the easiest way possible, this is the tutorial for you. Deploy in 5 minutes.

Hi! My name is Nacho Iacovino ([@nachoiacovino](https://twitter.com/nachoiacovino)), and I'm the Developer Advocate at Clerk. In this guide, I will teach you how to deploy Clerk using Vercel. This is the fastest and easiest way to set up a new application, complete with all the auth features provided by Clerk. In just a few minutes, you’ll create an app, deploy it, and set up your local environment.

If you prefer to follow this tutorial on video, you can [watch it here](https://www.youtube.com/watch?v=6kXKaQVv-k4).

To get started, go to [clerk.com](https://clerk.com) and sign into your account. If you don’t have an account yet, click “Get started for free” and create an account.

## Quick start

Once signed in, you’ll land your Applications page. Let's click **Create application** to create a new application.

![Quick start screenshot](./f058f4cdb1fbbc2500a4e397c49b80ad3b96d101-1920x947.webp "Starting page, here you will find a \"Create application\" button.")

When prompted, choose **Quick start with Next.js and Vercel**.

![Quick start screenshot](./b2ea95ec5f659b9e0cf2813ea7693787821c962a-631x448.webp "Two options, a standard setup and a \"Quick start with Next.js and Vercel\", we'll use this one.")

You will be directed to Vercel. Sign into your Vercel account, or create an account if you don’t have one. Choose a project name then click **Continue** to import the clerk-nextjs-starter repository.

![Quick start screenshot](./3bb14296a04f19420a8301fa163246c74db0030c-653x476.webp "Choose a project name and hit \"Continue\".")

## Install Clerk

Next, let's install the Clerk integration to connect Clerk to Vercel. When prompted, click **Install**. A new window will pop up. Follow the instructions to create a new Clerk application to connect to this Vercel project. Choose an application name and a brand color for your app. By default, the Clerk application name is the same as the Vercel project.

![Install Clerk screenshot](./f9d3d6baf359059b0a30c0bc517c9760dcaf07e3-800x599.webp "Add a Clerk application name and a brand color, and hit \"Create application\".")

Next, you will create a Git repository for your project. You can choose to use GitHub, GitLab, or BitBucket. For this tutorial, we'll use GitHub. Choose a repository name and click **Continue**.

![Install Clerk screenshot](./cf9010cc557956e8b827179a346a82207c1c1dff-651x474.webp "Create the Git repository on GitHub.")

## Deploy the project

On the Import Project screen, Clerk sets the necessary environment variables for you, so you don't have to do anything. Simply click Deploy.

![Deploy the project screenshot](./f6579e44e558e59d912581c25291814aa3bb95da-652x765.webp "Import the project and Deploy, Clerk adds the necessary Environment Variables for you")

Vercel will create and deploy the new Git repository. This step may take a few minutes. After the process is complete, you should see a congratulatory screen.

![Deploy the project screenshot](./a92b293486a2145858faef16946ceb3c9dc1efa0-841x276.webp "\"Congratulations!\" screen with a link to Visit the project.")

You can visit your deployed application by clicking Visit. You can see mine [here](https://clerk-nextjs-vercel.vercel.app)!

## Clone the project locally

The next step is to clone the newly-deployed repository to your local machine. Go to your Git provider, open the repository, and find the URL to clone the repository.

![Clone the project locally screenshot](./9f4a6980f39b251c0658287a75c4881c89928feb-1243x450.webp "GitHub page of the project so you can clone it.")

Open your local machine’s command line interface and navigate to the folder where you want to install your project, then paste the following code snippet:

```sh
git clone <repo_url>
```

Next, open the project and run `yarn install`

After the installation process completes, run `yarn dev`. This is where the magic happens!

Note: If you haven’t previously used Vercel on your local machine, you’ll have to sign in using a [link sent to your email](/blog/magic-links) before running `yarn dev`.

You will be prompted to set up link this local project with the Vercel project. Respond **Y** to each prompt.

And voilà! Your app is now running on `localhost:3000` —you can open it and see everything already working. Create an account on your app and take a minute to explore its features.

## Modify settings

Now that your app is up and running, you can configure user management and theme settings provided by Clerk at [https://dashboard.clerk.com](https://dashboard.clerk.com). Navigate to your application and choose which instance you would like to work on. Each Clerk project has 3 instances: Development, Staging, and Production. Instances are independent and do not share users or settings between them, so you can try different configurations before pushing them live.

![Modify settings illustration](./6f42dfa0338c8366a451105dfb35f885bb5a9f35-1920x947.webp "Different instances of a Clerk app. Development / Staging / Production.")

Any changes made will be applied to your project without the need to modify code or re-deploy.

![Modify settings screenshot](./2e7f92556ec64ecd2a758f07619aee73fa98190a-1920x947.webp "Some of the settings you can modify on your Clerk app.")

Try different configurations and find what works best for your application!

You can also modify theme settings to match the look and feel of Clerk components with the rest of your app.

![Modify settings screenshot](./1500da74670907ae6de28f82ae0f329b3658f917-543x861.webp "Theming options you can modify on your Clerk app.")

And that's it! You just created a new application, deployed it with Vercel, and set up your local environment. No need to mess with complex backend configurations or worry about painful security customizations.

If you run into any problems, don't hesitate to contact me! I’m here to help. Check out my profile on Twitter and DM me at [@nachoiacovino](https://twitter.com/nachoiacovino).

Any feedback is appreciated!

---

# Introducing Clerk: All of user management, not just authentication
URL: https://clerk.com/blog/all-of-user-management-not-just-authentication.md
Date: 2021-01-07
Category: Company
Description: The task came with a sense of helplessness. We knew what "great" looked like, but it was impractical to build all of that functionality.

![--- screenshot](./3537bb21b9137a72b75315872c03b0a97678aef2-2000x914.webp "Google user management")

We thought authentication-as-a-service vendors might ease our pain, but over and over again, we were disappointed by how much extra work was necessary. We never understood why until one friend quipped, *"auth-as-a-service really just solves half of 2-factor auth."*

Then it clicked. **We needed all of user management, not *just* authentication.** And we realized if we could solve this problem, countless others could benefit, too.

Today, we're absolutely thrilled to launch Clerk: **user management as-a-service**. We're solving the whole problem, from frontend to backend, with beautiful UIs and elegant APIs. Our architecture pulls user management out of the way, so developers can focus on what makes their software truly special.

![Today, we're absolutely thrilled to launch Clerk: user management as-a-service. We're solving the whole problem, from frontend to backend, with beautiful UIs and elegant APIs. Our architecture pulls user management out of the way, so developers can focus on what makes their software truly special. screenshot](./a37e8ca7365432384210b4b61e7c11d631148c14-2000x1016.webp "Clerk user management")

Our launch today includes UI components for Sign Up, Sign In, User Profile, and what we're calling the "User Button." They can be mounted directly in your application, or you can redirect users to a Clerk-hosted page on accounts.yourdomain.com.

Best of all, the components will automatically update as our team optimizes their design, develops new features, and adds support for the latest in account security.

While today marks an exciting milestone for Clerk, this is truly just a "minimum viable product." The roadmap ahead will bring many features to better support developers and their end users:

- SDKs for additional languages and frameworks
- Additional OpenID Connect and OAuth providers
- Additional 2-step verification factors like TOTP and WebAuthN
- Session management and revocation in the User Profile
- Team management and enterprise authentication like SAML

Need help with something you don't see listed? [Make a request](https://clerk.com/contact/support).