Is it needed on the frontend?

Hey @giuse,

Good question. We’ve disabled certain Wordfence files on the frontend (except our login and home pages). To offload assets, we’re using the plugin, Perfmatters. Below is what our set-up looks like. Review it. It will help you.

Wordfence support may have a different take on this. Meanwhile, everyting is working well for us (e.g., detection and blocking capabilities of Wordfence).

Hope this helps a bit.

Cheers!

—————–

View post on imgur.com

Hi @giuse,

I work for Wordfence — if you are using a plugin that disables entire plugins selectively, I would not recommend disabling Wordfence on any pages. The firewall can block various kinds of attacks that can occur on regular pageloads, including viewing posts/pages, the home page, and so on, and if it is disabled, it cannot provide protection. Some plugins may also expose login functionality on pages other than the login page, so login-related features may be necessary on regular pageloads as well.

If you are talking about only CSS or Javascript, Wordfence only loads these files on pages where they may be necessary. Some Javascript and CSS loads only for admins, which you might see on the front end of the site while logged in as an admin, but they should not load for regular visitors. Depending on which features you are using, there may be some Wordfence CSS and Javascript on the login page for all users, which is necessary for those features to work.

@generosus : The suggestions you made may work for you, but this can prevent some necessary styles or scripts from loading, for example, if there is an admin notice because of a configuration problem, or if a false positive block occurs and the admin needs to add it to the allowlist. Please don’t suggest changes that may break functionality for other users.

-Matt R, Wordfence QA Lead

Hi @generosus,, @wfmattr

Thank you @generosus for your suggestion and for sharing your experience.

Thank you @wfmattr for your detailed answer.
It’s still not totally clear to me. I still have some questions. You wrote:

The firewall can block various kinds of attacks that can occur on regular pageloads, including viewing posts/pages, the home page, and so on

Does Wordfence protect the site on the frontend with 1) JavaScript, 2) PHP, 3).htaccess, or 4) a combination of them?
If the answer is 2) PHP, how can it protect the website on the frontend when you have a caching plugin, or other caching systems that run on the server? I don’t think it can do it only with PHP, in another case it would fail every time the page is served by cache, but correct me if I’m wrong.

If the answer is 3) .htaccess, I can safely deactivate Wordfence on the frontend because the .htaccess file would run in any case even if Wordfence is disablled on a specific page (but globally active), can’t I?

If the answer is 2) JavaScript, I have an additional question: how can it protect the site with JavaScript on the frontend? This would mean the protection starts after the document is sent to the browser, but can it protect for attacks to the server?

If the answer is 4) a combination of 1), 2), 3), how can it work with caching plugins (PHP would be involved)?

Can you please clarify those points?

Thank you very much

Best regards

Jose

Hi Jose,

Wordfence’s firewall runs in PHP. A few Wordfence features use .htaccess to block specific files, like an exposed log or configuration file, if any are found. Javascript is used to support a few features, but not to block attacks.

Caching is generally not a problem because attacks require PHP to run, in order to modify anything on the server — if a hit comes in that can be served from cache via .htaccess rewrite rules or an external cache like Varnish, then no PHP code is running on your server in order to serve that hit. Some cache plugins do have an option to serve content using PHP, but Wordfence will normally run during those hits as well.

If there isn’t a cached page available for a visitor’s request, then PHP runs including the Wordfence firewall, so firewall rules can be applied to block malicious hits, if necessary.

-Matt R, Wordfence QA Lead

Hey @wfmattr,

Given your feedback, we have re-activated all WF files in the backend and frontend.

Thank you!

Hello @wfmattr,

I am following this thread with @giuse proposals, and the truth is that it is not completely clear, whether or not WordFence can be disabled on certain frontend pages.

From what I read, it seems that even if no WF routine is being used, it should always be enabled, but for what?

Hey @boomerangz,

Since this topic has already been resolved, please consider opening a new topic to address your concerns.

Until then and based on the info shared by @wfmattr, I highly recommend leaving Wordfence active on all pages and posts.

From our analysis, Wordfence only adds 27.2 kb of payload to each page or post — a small price to pay to keep our website(s) safe.

In the end, I wouldn’t count on Team Wordfence ever recommending disabling any of their plugin assets on any page or post.

Cheers ??

Hello @generosus

Thank you for your clarification.

Greetings.