# Clerk Blog — Engineering — Page 3

# How we use End To End tests to bulletproof our authentication flows across browsers
URL: https://clerk.com/blog/how-we-use-end-to-end-tests-to-bulletproof-our-authentication-flows-across-browsers.md
Date: 2021-06-11
Category: Engineering
Description: Due to the evolution of tooling and the shift towards high-velocity product development, End To End testing is a regular topic of discussion for small teams.

At Clerk, we use End To End testing to create bulletproof authentication flows across browsers.

## The 10,000 ft view of the End To End landscape

In the past, End To End testing was almost exclusively considered a Quality Assurance Engineering topic. For one reason or another, the development of test automation pipelines and application workflow validation tests were not so popular with software engineers. That view has gradually become dated and replaced with the growing popularity of tools like Cypress, Puppeteer, Playwright, and even the latest version of Selenium.

![How We Use End To End Tests To Bulletproof Our Authentication Flows Across Browsers guide illustration](./490c57865ef4011f0134f142c2fee8d3057ad7fd-2000x1404.png)

The growth of those tools should not be seen as a simple technical advancement, but instead as an immediate answer to the growing need to efficiently and effectively validate fast moving development cycles of agile teams. At Clerk we deploy multiple times per day, and without these tools it would be impossible to ensure reliability.

## The high bar for reliability at Clerk

As a solution for authentication and user management, Clerk must maintain exceptionally high reliability, even as our product and team expands rapidly around our core offering. It is critical that end-users can always access their accounts quickly, even through edge cases like originally signing up with Google, then trying to sign in with email instead.We also take great pride in our developer experience, and often jump through hoops to ensure that Clerk works consistently across development, staging, and production environments and across all browsers.To keep reliability high across our myriad of flows - and importantly, to give our own development team confidence that our product won't break with new deploys - it became clear the most pragmatic solution was to develop an End To End test suite.

## Laying out our needs

These were our initial needs exactly as voiced by our team:

- **Cross-browser**: The suite needs to cover all major browsers with as little external service interaction as possible.
- **Happy to code in**: Meaning TypeScript. Most probably Frontend Engineers should be able to write and maintain the tests for the suite (*with as much joy as possible*).
- **Support containerized deployment**: The suite needs to be portable enough to run on a GitHub Action workflow.

## Choosing a platform

After investigating Selenium, Puppeteer, WebDriverIO, Cypress, and Playwright and weighing each platform against our needs, we decided to go with Playwright.

Although it felt less hyped, as a team we felt really confident in the architecture behind Playwright, its stellar documentation and tooling, and the excellent community backing the effort.

We will describe our exact selection process in a later post, but most critically, we appreciate the ability to execute our workflows across Chromium, WebKit and Firefox with so much ease and fine grained control.

![How We Use End To End Tests To Bulletproof Our Authentication Flows Across Browsers guide illustration](./8a588e6ff8136f408783a02c95ef6cbd64c402ef-1048x433.png)

## How the suite is orchestrated

Our End to End test suite is a separate system from our main codebase as we have seen this pattern working really well for most applications.

Its main components as a Node.js application written in TypeScript are:- **Playwright** as the browser automation framework.

- **Jest** as the test suite runner.
- [jest-playwright](https://github.com/playwright-community/jest-playwright) to connect Jest and Playwright as it makes our lives so much easier.
- [Faker.js](https://github.com/faker-js/faker) to create API fixtures that fit our needs for the sign-up and sign-in processes fixtures.
- [Page Objects](https://playwright.dev/docs/pom) as the main pattern representing the interaction facade with our application views in code.

These components have proved to work together seamlessly while staying welcoming to our frontend engineering team. One of our main goals was to ensure that new teammates could understand the system quickly and create new tests, and so far this structure has exceeded our expectations.

## Delivery of the suite on our day to day efforts

To keep us safe from accidental regressions, the test suite must run (and pass!) before any merge to production. To automate this process, integration with our Continuous Integration (CI) tooling was essential.

We run our CI through GitHub Actions, and fortunately, the Playwright team has created GitHub Action tools to simplify triggering the test suite. Paired with Vercel preview deployments, which is where most of our CI tasks take place, both Actions fit the spot quite nicely for End to End suite scenarios. The Playwright team has also created a GitHub action to quickly bootstrap Playwright tests.

The final action file that triggers our End to End suite on every pull request looks something like this:

```bat
jobs:
  e2e:
    if: github.event.deployment_status.state == 'success'
    name: End to End
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]
    steps:
      - uses: actions/checkout@v2
      - uses: microsoft/playwright-github-action@74fbf9d1a7c5d8735dab59804da3fdd367a98020
      - uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Run Playwright tests
        run: cd e2e && npm install && npm run test
```

If the action succeeds, we are good to go!

## Parting words

This was a really brief overview of how we went about designing our End to End test suite at Clerk. As Clerk and our customers' needs continue to evolve, we will continue to share our experiences with Playwright and any new tools we adopt.

***P. S.** We have open sourced a template for starting up your own End To End suite using Playwright, so feel free to try it out! [https://github.com/clerkinc/playwright-e2e-template](https://github.com/clerkinc/playwright-e2e-template)*

---

# 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.