Back Button Security Concerns

[drfraker]

I believe there may be some issues around the way Inertia handles it's ajax calls in the presence of Cache-Control headers that are put in place for security. See the link below for the closed issue where this is discussed.

The basic premise of cache control headers is that if you add 'no-cache, no-store' to cache control the app will require a full page reload even when a user clicks on the back button in the browser. This is a great way to prevent sensitive data from being displayed after a user logs out of an application and the back button is clicked. Since the app now has to make a full server request due to no cache history, the information will not be displayed and the user will be redirected back to the login page by the server.

When using Inertia this behavior is not present. If you log into an app with Inertia where the Cache-control headers are present to protect back button clicks, logout and press the back button you still see the sensitive pages.

Is there a way to check for this header and redirect to login if the session is no longer valid?

Originally posted by @drfraker in #102 (comment)

[drfraker]

For reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

Specifically this directive:
no-store
The response may not be stored in any cache. Although other directives may be set, this alone is the only directive you need in preventing cached responses on modern browsers. max-age=0 is already implied. Setting must-revalidate does not make sense because in order to go through revalidation you need the response to be stored in a cache, which no-store prevents.

[claudiodekker]

Hi,

Unless I'm mistaken, this really is not a bug, and no-store is not consider to be a security feature. The HTTP 1.1 specification even describes that browsers should not be expected to respect http caching rules when clicking the back button:

User agents often have history mechanisms, such as “Back” buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.

However, this specification is outdated, and has been replaced by https://tools.ietf.org/html/rfc7234#section-6, which states:

User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation retrieved earlier in a session.

The freshness model (Section 4.2) does not necessarily apply to history mechanisms. That is, a history mechanism can display a previous representation even if it has expired.

This does not prohibit the history mechanism from telling the user that a view might be stale or from honoring cache directives (e.g., Cache-Control: no-store).

While this does mention that the freshness model does not necessarily apply, it doesn't explicitly tell that the history mechanism should be expected to honor cache directives either, so, instead, we'll take a closer look at Section 4.2:

Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload a resource. See Section 6 for an explanation of the difference between caches and history mechanisms.

Let's see if the no-store directive has anything more to offer us:

The "no-store" request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.

This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.

Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already stored response.

So, in conclusion, it's not really a bug, because history mechanisms are not http caches.

THAT SAID, since people keep complaining about it, and since we (Inertia) make HTTP requests and use History state as a cache of sorts, we might actually want to consider respecting the no-store directive. The only concerns that I have is that restoring a 'previous' state that is broken might cause more trouble than it's worth, because:

1. How would we know what 'page' to display?
2. If we display that page with no data, would it not cause javascript crashes due to missing values?

[reinink]

While I don't consider the current behaviour of Inertia.js to be "broken", I do understand why people want this behaviour.

We could update Inertia to only save the page object in the event that the Cache-Control header does not include no-cache or no-store, and then while navigating history, we could reload the data from the server. Then, in the event that the session expired, the user would be redirected to the login page. I haven't actually tested this, but I think in theory it should be possible. I do worry how well scroll restoration would work if you're waiting for a full page visit to occur when clicking back. I also worry what would happen if you click back/forward in the history quickly. Presumably we'd cancel the in-progress history restoration requests, but this could get ugly.

I wonder if there is a simpler way to handle this problem. Something like this:

// Track if the user is logged in (in localStorage) after every Inertia visit.
// This can be done using the Inertia "success" event, and by inspecting the page props.
Inertia.on('success', event => {
  window.localStorage.setItem('loggedIn', event.detail.page.props.auth.user !== null)
})

// When the user navigates, check if they are logged in.
// If they are not, stop the propagation to prevent Inertia from restoring the page.
// Then, instead, redirect them to the login page.
window.addEventListener('popstate', event => {
  if (window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

The only hiccup with this approach is that this will also prevent navigating to other public pages. You could manually check for that though:

window.addEventListener('popstate', event => {
  // Only prevent history navigation for private pages.
  const publicUrls = ['/login', '/reset-password']
  if (!publicUrls.includes(event.state.url) && window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

And of course, you could get fancy with this, and automatically mark pages as "private" server-side in your page props:

window.addEventListener('popstate', event => {
  // Only prevent history navigation for private pages.
  if (event.state.props.private && window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

This actually achieves the desired behaviour very well. The biggest "issue" I see here is that for every click back in history (after logging out), this "eats" one of the history entries. This is because it's NOT possible to prevent (event.preventDefault()) a popstate event.

[drfraker]

I really appreciate your time spent looking into this

You both have a much better idea that I do as to what would work best in the context of inertia. So I can't really add anything to that discussion.

I don't want to speak for anyone else, but I think anyone who is looking for this behavior would be ok with a few trade offs. If an app doesn't have "cache-content: no-store" headers, I imagine it would have no impact at all.

Let me know if I can help test or anything else.

[RedFoxxxxx]

Hello everyone, I seem to also have a problem with this one. It goes back to dashboard even after log out. I tried the solution of @reinink but it didn't work for me. Any ideas on how to work around this?

[RedFoxxxxx]

I think I have found a work around. I just modified the code of @reinink to my own preference. Thanks.

[christoomey]

I've continued to explore this from the server side which would really be the ideal place to solve it, but unfortunately no combination of headers seems to get the browser (Chrome in my current testing) to behave as expected.

I decided to give it a quick poke based on the snippets @reinink shared above and was able to get something that roughly matches my goals, specifically:

1. Allow for normal back-forward browser cache handling following GET requests
2. Force full page reload when hitting back after any non-get request:

let lastRequestMethod = null

Inertia.on('start', (event) => {
  lastRequestMethod = event.detail.visit.method
})

window.addEventListener('popstate', (event) => {
  if (lastRequestMethod !== 'get') {
    event.stopImmediatePropagation()
    window.location.href = event.state.url
  }
})

It only adds this behavior for the single preceding request, but I believe it would degrade to the normal browser behavior, so I may be able to convince myself that this is enough and is a tolerable amount of mucking about in core browser logic.

[progdog-ru]

While I don't consider the current behaviour of Inertia.js to be "broken", I do understand why people want this behaviour.

We could update Inertia to only save the page object in the event that the Cache-Control header does not include no-cache or no-store, and then while navigating history, we could reload the data from the server. Then, in the event that the session expired, the user would be redirected to the login page. I haven't actually tested this, but I think in theory it should be possible. I do worry how well scroll restoration would work if you're waiting for a full page visit to occur when clicking back. I also worry what would happen if you click back/forward in the history quickly. Presumably we'd cancel the in-progress history restoration requests, but this could get ugly.

I wonder if there is a simpler way to handle this problem. Something like this:

// Track if the user is logged in (in localStorage) after every Inertia visit.
// This can be done using the Inertia "success" event, and by inspecting the page props.
Inertia.on('success', event => {
  window.localStorage.setItem('loggedIn', event.detail.page.props.auth.user !== null)
})

// When the user navigates, check if they are logged in.
// If they are not, stop the propagation to prevent Inertia from restoring the page.
// Then, instead, redirect them to the login page.
window.addEventListener('popstate', event => {
  if (window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

The only hiccup with this approach is that this will also prevent navigating to other public pages. You could manually check for that though:

window.addEventListener('popstate', event => {
  // Only prevent history navigation for private pages.
  const publicUrls = ['/login', '/reset-password']
  if (!publicUrls.includes(event.state.url) && window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

And of course, you could get fancy with this, and automatically mark pages as "private" server-side in your page props:

window.addEventListener('popstate', event => {
  // Only prevent history navigation for private pages.
  if (event.state.props.private && window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

This actually achieves the desired behaviour very well. The biggest "issue" I see here is that for every click back in history (after logging out), this "eats" one of the history entries. This is because it's NOT possible to prevent (event.preventDefault()) a popstate event.

While I don't consider the current behaviour of Inertia.js to be "broken", I do understand why people want this behaviour.

We could update Inertia to only save the page object in the event that the Cache-Control header does not include no-cache or no-store, and then while navigating history, we could reload the data from the server. Then, in the event that the session expired, the user would be redirected to the login page. I haven't actually tested this, but I think in theory it should be possible. I do worry how well scroll restoration would work if you're waiting for a full page visit to occur when clicking back. I also worry what would happen if you click back/forward in the history quickly. Presumably we'd cancel the in-progress history restoration requests, but this could get ugly.

I wonder if there is a simpler way to handle this problem. Something like this:

// Track if the user is logged in (in localStorage) after every Inertia visit.
// This can be done using the Inertia "success" event, and by inspecting the page props.
Inertia.on('success', event => {
  window.localStorage.setItem('loggedIn', event.detail.page.props.auth.user !== null)
})

// When the user navigates, check if they are logged in.
// If they are not, stop the propagation to prevent Inertia from restoring the page.
// Then, instead, redirect them to the login page.
window.addEventListener('popstate', event => {
  if (window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

The only hiccup with this approach is that this will also prevent navigating to other public pages. You could manually check for that though:

window.addEventListener('popstate', event => {
  // Only prevent history navigation for private pages.
  const publicUrls = ['/login', '/reset-password']
  if (!publicUrls.includes(event.state.url) && window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

And of course, you could get fancy with this, and automatically mark pages as "private" server-side in your page props:

window.addEventListener('popstate', event => {
  // Only prevent history navigation for private pages.
  if (event.state.props.private && window.localStorage.getItem('loggedIn') === 'false') {
    event.stopImmediatePropagation()
    window.location.href = '/login'
  }
})

This actually achieves the desired behaviour very well. The biggest "issue" I see here is that for every click back in history (after logging out), this "eats" one of the history entries. This is because it's NOT possible to prevent (event.preventDefault()) a popstate event.

Please place this information in the documentation on your site.