Web Application Potentially Vulnerable to Clickjacking #1807

New Issue

OVERLORD · 2026-02-05T01:56:29+03:00

OVERLORD commented

2026-02-05 01:56:29 +03:00

Originally created by @isgroup on GitHub (Jul 31, 2020).

Describe the bug

BookStack is not protected against Clickjacking (HTTP headers X-Frame-Options or Content-Security-Policy are not sent).

Steps To Reproduce

curl any BookStack page, even the login/homepage, and you will not see such headers.

Expected behavior

The application should be secure by default.

Return the X-Frame-Options or Content-Security-Policy (with the 'frame-ancestors' directive) HTTP header with the page's response. This prevents the page's content from being rendered by another site when using the frame or iframe HTML tags.

Screenshots

N/A

Your Configuration (please complete the following information):

BookStack Docker Version (latest)

Additional context

The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses. This could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions.

X-Frame-Options has been proposed by Microsoft as a way to mitigate clickjacking attacks and is currently supported by all major browser vendors.

Content-Security-Policy (CSP) has been proposed by the W3C Web Application Security Working Group, with increasing support among all major browser vendors, as a way to mitigate clickjacking and other attacks. The 'frame-ancestors' policy directive restricts which sources can embed the protected resource.

Note that while the X-Frame-Options and Content-Security-Policy response headers are not the only mitigations for clickjacking, they are currently the most reliable methods that can be detected through automation. Therefore, this plugin may produce false positives if other mitigation strategies (e.g., frame-busting JavaScript) are deployed or if the page does not perform any security-sensitive transactions.

https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet

https://en.wikipedia.org/wiki/Clickjacking

Originally created by @isgroup on GitHub (Jul 31, 2020). **Describe the bug** BookStack is not protected against Clickjacking (HTTP headers X-Frame-Options or Content-Security-Policy are not sent). **Steps To Reproduce** `curl` any BookStack page, even the login/homepage, and you will not see such headers. **Expected behavior** The application should be secure by default. Return the X-Frame-Options or Content-Security-Policy (with the 'frame-ancestors' directive) HTTP header with the page's response. This prevents the page's content from being rendered by another site when using the frame or iframe HTML tags. **Screenshots** N/A **Your Configuration (please complete the following information):** BookStack Docker Version (latest) **Additional context** The remote web server does not set an X-Frame-Options response header or a Content-Security-Policy 'frame-ancestors' response header in all content responses. This could potentially expose the site to a clickjacking or UI redress attack, in which an attacker can trick a user into clicking an area of the vulnerable page that is different than what the user perceives the page to be. This can result in a user performing fraudulent or malicious transactions. X-Frame-Options has been proposed by Microsoft as a way to mitigate clickjacking attacks and is currently supported by all major browser vendors. Content-Security-Policy (CSP) has been proposed by the W3C Web Application Security Working Group, with increasing support among all major browser vendors, as a way to mitigate clickjacking and other attacks. The 'frame-ancestors' policy directive restricts which sources can embed the protected resource. Note that while the X-Frame-Options and Content-Security-Policy response headers are not the only mitigations for clickjacking, they are currently the most reliable methods that can be detected through automation. Therefore, this plugin may produce false positives if other mitigation strategies (e.g., frame-busting JavaScript) are deployed or if the page does not perform any security-sensitive transactions. https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet https://en.wikipedia.org/wiki/Clickjacking

OVERLORD added the 🛠️ Enhancement 🔒 Security labels 2026-02-05 01:56:29 +03:00

OVERLORD closed this issue

2026-02-05 01:56:34 +03:00

OVERLORD commented

2026-02-05 01:56:41 +03:00

@codegeek1001 commented on GitHub (Sep 16, 2020):

Wouldn't you set this at the server level ? For example, in nginx, you can do:

add_header X-Frame-Options "SAMEORIGIN";

add_header X-XSS-Protection "1; mode=block";

add_header X-Content-Type-Options "nosniff";

@codegeek1001 commented on GitHub (Sep 16, 2020): Wouldn't you set this at the server level ? For example, in nginx, you can do: add_header X-Frame-Options "SAMEORIGIN"; add_header X-XSS-Protection "1; mode=block"; add_header X-Content-Type-Options "nosniff";

OVERLORD commented

2026-02-05 01:56:45 +03:00

@isgroup commented on GitHub (Sep 16, 2020):

@codegeek1001 you can do that also in the webserver configuration, or in a reverse proxy, or just document it.

Still the safest option is to delivery the application "secure by default", in this case an header() call in the PHP code.

@isgroup commented on GitHub (Sep 16, 2020): @codegeek1001 you can do that also in the webserver configuration, or in a reverse proxy, or just document it. Still the safest option is to delivery the application "secure by default", in this case an header() call in the PHP code.

OVERLORD commented

2026-02-05 01:56:50 +03:00

@ssddanbrown commented on GitHub (Dec 11, 2020):

Thanks for advising @isgroup.

I can see the value in having this additional security by default.
We'd have to allow an option to set the trusted domains as there are legitimate existing users using the platform within an iframe.

Think we might aswell use the CSP approach as that's the more modern way. CSP supports being defined as multiple headers so we could set a frame-ancestors specific CSP header. Not sure if that could possible cause issues for people that also define CSP on the server side though. Responsibilities do get a little messy.

@ssddanbrown commented on GitHub (Dec 11, 2020): Thanks for advising @isgroup. I can see the value in having this additional security by default. We'd have to allow an option to set the trusted domains as there are legitimate existing users using the platform within an iframe. Think we might aswell use the CSP approach as that's the more modern way. CSP supports being defined as multiple headers so we could set a `frame-ancestors` specific CSP header. Not sure if that could possible cause issues for people that also define CSP on the server side though. Responsibilities do get a little messy.

OVERLORD commented

2026-02-05 01:56:52 +03:00

@ssddanbrown commented on GitHub (Jan 2, 2021):

I've just committed 92922288dd with functionality to address this.

The CSP header will now be set, with a default value of 'self'. In addition, a new .env option is available:

ALLOWED_IFRAME_HOSTS="https://example.com https://a.example.com"

When this is set, the extra provided hosts will also be added to the header and cookies security options will also be altered to allow the third-party usage.

This will be included within the next feature release, v0.31.

Thanks again for raising @isgroup, I did not know about iframe control via CSP before.

@ssddanbrown commented on GitHub (Jan 2, 2021): I've just committed 92922288dd55ce0f77acc83eea9068cad28dccd9 with functionality to address this. The CSP header will now be set, with a default value of 'self'. In addition, a new `.env` option is available: ```shell ALLOWED_IFRAME_HOSTS="https://example.com https://a.example.com" ``` When this is set, the extra provided hosts will also be added to the header and cookies security options will also be altered to allow the third-party usage. This will be included within the next feature release, v0.31. Thanks again for raising @isgroup, I did not know about iframe control via CSP before.

OVERLORD commented

2026-02-05 01:56:54 +03:00

@isgroup commented on GitHub (Jan 18, 2021):

Cool @ssddanbrown ^_^

@isgroup commented on GitHub (Jan 18, 2021): Cool @ssddanbrown ^_^

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1807