Skip to main content
All CollectionsSecurity & ComplianceFlusk
How do I fix the Page Access Protection issue flagged by Flusk?
How do I fix the Page Access Protection issue flagged by Flusk?
Updated this week

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.

Note: Only "Go to page" action works in this case. Using the "Go to previous page" won't work here, as it needs the front-end context to know which page to redirect to, and we want this action to run in the back-end.

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

Type

Is safe?

Do when a condition is true

Client-side

No

Current User is logged in

Server-side

Yes

Current User is logged out

Server-side

Yes

Page is loaded

Server-side

Yes

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.

Solution

You absolutely need to meet the following requirements:

  • Use one of the following events

    • Current User is logged in

    • Current User is logged out

    • Page is loaded

  • You should only have 1 action in your workflow

  • Your condition should not rely on a value that needs the page to be loaded to be evaluated (no custom states, for example)

Did this answer your question?