Demo Issue Documentation
Updated over a week ago

Note: this is a demo documentation for example purposes.

This issue is being fired when a page is defined as sensitive and it has no proper 302 redirection to ensure the data is safe and the page is never entirely loaded.

To illustrate this issue, consider the following scenario:

You have a page called "admin" that is restricted to users with admin access because it contains sensitive data such as private pictures of users, and allows admins to take certain actions.

In this case, you might want to check if the current user has the admin role and, if they do not, redirect them to the homepage. While this may seem like a logical approach, it is important to understand that redirections can be problematic.

It is essential to have a thorough understanding of how redirections work to avoid this type of issue.

Understanding redirections

When you try to load a page, you are making an HTTP request to the Bubble servers to retrieve the content of the page. The response from the server can be one of five different types:

  1. Informational (100 to 199)

  2. Successful (200 to 299)

  3. Redirect (300 to 399)

  4. Client error (400 to 499)

  5. Server error (500 to 599)

As you can see, there are multiple possibilities for redirection codes within the 3rd category. The most important thing to understand about redirection is that if you receive a 3xx response from the server, no content will be downloaded and you will be immediately redirected to the next page.

This is known as a "server-side redirect."

In contrast to a server-side redirect, a "client-side redirect" is a manual redirection that is initiated by a JavaScript instruction. It is important to note that JavaScript needs to be downloaded before it can be executed. This is how a client-side redirect works:

The admin page is downloaded, and then JavaScript is executed to tell the browser to go to another page. However, by this time, all of the data has already been downloaded, making it too late to prevent unauthorized access.

It is important to be aware of the limitations of client-side redirects and to use appropriate security measures to protect sensitive information.

How to set up clean server redirections?

To set up server-side redirections, you need to use the "Go to page" action without relying on any client-side conditions or events. For example, you could set up a redirection using the « User is logged out" to see what happens. Let’s see what we get:

To verify that you are correctly using a server-side redirect, you can use a redirect checker such as this one. This will allow you to determine whether you are receiving a 3xx or 2xx response from the server.

We indeed have a 302 redirect on the page « redirect », then we’re redirected to the page « index » which is fetched with a 200 code.

All good!

Let’s try another method and use a client-side condition. We will use the « Do when a condition is true » event (that gets executed once the page is loaded), and check if the Current User is an Admin or not:

Let’s check the response code from the redirect checker:

We got a 200 code. This indicates that the page has been completely downloaded and that no server-side redirect has been applied.

Let’s resume client-side and server-side redirections for main events:

Event name


Is safe?

Do when a condition is true



Current User is logged in



Current User is logged out



Page is loaded



Caution: if you add a client-side condition on a server-side redirection, the page will wait for the client-side condition to be checked and then apply the redirection. Your safe redirection will not be safe anymore.


In order to define a proper server-side redirection, you have to create a redirection based on :

  • A page is loaded event

  • A condition that can be evaluated server side

Did this answer your question?