Recently Browsing 0 members
No registered users viewing this page.
By Chris Bennett
Plenty of posts on the forum relating to Content Security Policy (CSP) and how to integrate it with Processwire.
It's not too hard to implement a decent htaccess CSP that will get you a solid B+ at Mozilla Observatory.
If you're after A+ it's a little harder because of all the back-end stuff... until you realize it's surprisingly easy.
After a lot of testing, the easiest way I found was to specify only what is needed in the htaccess and then add your required CSP as a meta in your page template.
Plenty of people have suggested similar. Works very easily for back-end vs front-end, but gets complicated if you want front page editing.
Luckily, a little php will preserve back-end and front page editing capabilities while allowing you to lock down the site for anyone not logged in.
None of this is rocket science, but CSPs are a bit of a pain the rear, so the easier the better, I reckon 😉
The only CSP I'd suggest you include in your site htaccess is:
Header set Content-Security-Policy "frame-ancestors 'self'" The reason for this is you can't set "frame-ancestors" via meta tags.
In addition, you can only make your CSP more restrictive using meta tags, not less, so leaving the back-end free is a solid plan to avoid frustration.
Then in your public front-facing page template/s, add your desired Content Security Policy as a meta tag.
Please note: your CSP should be the first meta tag after your <head>.
<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no"> If you haven't got Front Page Editing enabled, this works fine by itself.
Just one extra step is needed to make sure you don't have to worry either way.
The easiest way I found to allow both CSP and front page editing capabilities is the addition of a little php, according to whatever your needs are.
Basically, if the user is a guest, throw in your CSP, if they're not do nothing.
It's so simple I could have kicked myself when it finally dawned on me.
I wish it had clicked for me earlier in my testing, but it didn't so I'm here to try to save some other person a little time.
<!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <?php endif; ?> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no">
If you want it a bit more involved then you can add additional tests and be as specific as you like about what pages should get which CSP.
For example, the following is what I use to expand the scope of the CSP only for my "map" page:
<?php $loadMap = $page->name === "map"; ?> <!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="default-src 'none'; base-uri 'self'; manifest-src 'self'; form-action 'self'; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com; img-src 'self' data:<?php echo ($loadMap) ? " https://maps.googleapis.com https://maps.gstatic.com" : ""; ?> https://www.google-analytics.com; script-src 'self' <?php echo ($loadMap) ? "https://maps.googleapis.com " : ""; ?>https://www.google-analytics.com https://www.googletagmanager.com; style-src 'self' <?php echo ($loadMap) ? "'unsafe-inline' https://fonts.googleapis.com" : ""; ?>"> <?php endif; ?> Hope this saves someone a little time testing.
Hello forum, this is my first security related post, so I'm a bit of a newbie.
I understand that when I have direct front-input from user I should sanitize the input, but how about when I use a secret key for showing a API for a third-party supplier? Should I sanitize the input->get() key?
I've tested this issue and I tried ?key=<?php echo $page->field; ?> And without adding any sanitization it comes back: /?key=<?php%20echo%20$page->field;%20?>
So can I rely on this, or should I still use $sanitizer just in case?
Thanks for the help!
We have many booking calendars made with ProcessWire (own databases) and I want to do a web app (SQL) which allows user to log in. First, the user chooses the right calendar and then (s)he have to log in. The user can be from any of those calendars and the app is not running on ProcessWire (it can if necessary). So if there any way to make sure that the user has rights to the calendar (s)he tries to log in and if the password is correct.
Is there any better way to do this? I could also use PIN codes or something, but those need to be encrypted too.
Multiple ProcessWires A lot of users per ProcessWire Everyone can log in to the web app (when using right calendar)
By Jennifer Stock
Greetings. I would like to restrict access to certain sections of my organization's ProcessWire site using pubcookie. We are rolling out Shibboleth authentication later this year but for now, it seems I can only make use of our institution's single sign-on routine by utilizing rules in an .htaccess file.
I am wondering if there is a way to ask PW to apply these rules to certain pages in the site, whether via template type or location in the page tree:
AuthType UWNetID PubcookieAppID "MyApplication" require type staff faculty
By flydev 👊🏻
Originaly developped by Jeff Starr, Blackhole is a security plugin which trap bad bots, crawlers and spiders in a virtual black hole.
Once the bots (or any virtual user!) visit the black hole page, they are blocked and denied access for your entire site.
This helps to keep nonsense spammers, scrapers, scanners, and other malicious hacking tools away from your site, so you can save precious server resources and bandwith for your good visitors.
How It Works
You add a rule to your robots.txt that instructs bots to stay away. Good bots will obey the rule, but bad bots will ignore it and follow the link... right into the black hole trap. Once trapped, bad bots are blocked and denied access to your entire site.
The main benefits of Blackhole include:
Bots have one chance to obey your site’s robots.txt rules. Failure to comply results in immediate banishment.
Disable Blackhole for logged in users Optionally redirect all logged-in users Send alert email message Customize email message Choose a custom warning message for bad bots Show a WHOIS Lookup informations Choose a custom blocked message for bad bots Choose a custom HTTP Status Code for blocked bots Choose which bots are whitelisted or not
Install the module Create a new page and assign to this page the template "blackhole" Create a new template file "blackhole.php" and call the module $modules->get('Blackhole')->blackhole(); Add the rule to your robot.txt Call the module from your home.php template $modules->get('Blackhole')->blackhole(); Bye bye bad bots!