HTProtect – Protection shield (Demo)

HTProtectServer ShieldJoomla Security – always up to date.

Overview Backend access Protection shield Site scan Backups Help Center

Protection shield – main .htaccess

Most important settings

Exploit shield activeRecommended. Blocks known attacks (JCE, Novarain, Astroid …) via .htaccess and real-time firewall.Keep ruleset up to date automaticallyRecommended. Whenever HTProtect improves its protection ruleset (e.g. via an update), the shield is rewritten automatically – no more clicking “Secure now” on every site by hand. With a self-test: if anything fails it is rolled back instantly. An external or hand-edited .htaccess stays untouched.Harden upload foldersBlocks PHP in images/tmp/cache … – works even if the main .htaccess is deleted.Force HTTPS (301)Proxy setups are detected correctly via X-Forwarded-Proto.

Unify host name

Show advanced settings

The recommended settings are already active (via „Secure now“ on the overview). Here you can fine-tune everything in detail – if unsure, just leave it.

Basics & server

Joomla subdirectory (auto-detected)

Automatically detected from Joomla's base URL and kept in sync – no need (or option) to set it manually. If the site runs in a subdirectory, the detected path is shown here.

Search-engine-friendly URLs (Joomla router)Forwards requests to non-existent paths to index.php - a prerequisite for SEF URLs.

The /api interface (Joomla 4+) is configured in the Exploit shield section (route / block).

Pass through Authorization header under FastCGI/PHP-FPMImportant for the backend password protection and API tokens.Server base hardening (directory listing off, signature off, start files)Requires "AllowOverride Options" - disable on error 500. The self-test catches this automatically.Follow symbolic links (+FollowSymlinks)Only enable if your host requires it.Self-securing for templates/clonesFor pre-installed Joomla templates/app installers: if the protection shield is not (yet) active on a site, HTProtect writes it automatically on the first backend visit (with self-test and auto rollback). An existing foreign .htaccess is backed up and replaced first. Leave off for normal use.

Canonical address

Force HTTPS and www mode are above under „Most important settings“.

Canonical domain (empty = automatic)

Response headers

Apply server-wide (static files too) and replace duplicates – they complement Joomla’s ‘HTTP Headers’ plugin (CSP/nginx), without conflict.

Forbid embedding in foreign sites (X-Frame-Options)Protection against clickjacking.Forbid MIME type sniffing (nosniff)Standard security header (X-Content-Type-Options) – Joomla’s own default .htaccess sets it active too. If styling or JavaScript breaks after enabling, a third-party extension serves content with the wrong MIME type – then disable it here (or have the extension fixed).

Referrer policy

Remove version header (X-Powered-By)Enable HSTS (Strict-Transport-Security)Only useful with forced HTTPS and a valid certificate. Browsers remember HTTPS for 1 year.HSTS for subdomains tooOnly if ALL subdomains can do HTTPS.Window isolation (Cross-Origin-Opener-Policy)Can disrupt popup-based logins/payments - when in doubt, off.Disable device access (Permissions-Policy)Blocks camera, microphone, location, payment. Disable if the site uses such things.

Request filters

Reject injection patterns in the query stringNull bytes, path traversal, PHP stream wrappers, encoded calls, script tags etc.Reject foreign URLs as GET parameter valuesClassic remote-include protection. If an extension needs complete URLs as parameters, disable.Block diagnostic methods (TRACE/TRACK/DEBUG)Reject WordPress scan noise immediatelywp-admin, wp-login.php, xmlrpc.php & co. get a 403 instead of an expensive Joomla 404.

Exploit shield

Wards off known Joomla attacks (JCE, Novarain/Tassos, Astroid, com_ajax LFI ...) and generic attack classes – in two layers from one signature list: the .htaccess blocks GET attacks before PHP, the real-time firewall additionally catches POST attacks and uses new signatures instantly. This switch controls both.

On/off is above under „Most important settings“. Here are the details:

/api interface (Joomla 4+)

A complete /api block would have prevented the Joomla core leak CVE-2023-23752 (reading the configuration including database credentials) from the outset. Only block if no extension uses the Joomla web services.

Manage signatures individually (20)

JCE profile import (CVE-2026-48907) everyone (incl. logged in)Unauthenticated profile import in the JCE editor - start of the current RCE chain (enables PHP uploads). No legitimate frontend call.JCE webshell upload via plugin.rpc (CVE-2026-48907) guests onlyFile upload via the JCE file browser (plugin.rpc, method=upload). Applies only on the frontend; logged-in authors (legitimate editor upload) are unaffected.JCE Image Manager (legacy exploit) guests onlyClassic unauthenticated file upload via the JCE image manager (very old JCE versions).Novarain / Tassos Framework (com_ajax include) everyone (incl. logged in)CVE-2026-21627: unauthenticated PHP file inclusion via plg_system_nrframework through com_ajax (task=include).Astroid Framework (AJAX endpoint) everyone (incl. logged in)CVE-2026-21628: unchecked Astroid AJAX endpoint (upload/installation). Coarse match on com_ajax + astroid.Helix3 (JoomShaper): unauth com_ajax handler (file write/delete) guests onlyHelix3 < 3.1.1: the onAjaxHelix3 ajax handler checked neither login nor permission. Targets the dangerous unauth POST-body actions: save (write layout JSON into the active template), remove (delete a file via path traversal), import (overwrite template style settings) plus upload_image/remove_image/updateFonts. Legitimate guest actions (voting, load) and logged-in template use are unaffected. Fix: Helix3 3.1.1.Helix3 (JoomShaper): unauth com_ajax dispatcher (file write/delete, style injection) guests onlyHelix3 < 3.1.1: the front-end dispatcher (option=com_ajax with plugin=helix3) invoked onAjaxHelix3 BEFORE any token/permission check - unauthenticated save/import/remove/resetLayout/updateFonts/fontVariants (file write, path-traversal delete, template style injection, stored XSS). Blocks every GUEST call of this dispatcher on the front end (defense in depth, also catches ongoing scans) - complements the action-specific helix3-ajax signature with the bare dispatcher access. Logged-in template editing runs in the backend behind auth and is NOT affected; guest scope + waf_only. Fix: Helix3 3.1.1 (2026-06-29). Not to be confused with Helix Ultimate - separate product, own signature helixultimate-comajax.Helix Ultimate (JoomShaper): unauth com_ajax dispatcher (menu write/file/export) guests onlyHelix Ultimate < 2.2.7: the com_ajax handler onAjaxHelixultimate (option=com_ajax with plugin=helixultimate, action in the task param) ran BEFORE any login/permission check - an anonymous attacker could write into the menu settings (stored XSS reaching the admin session), delete files anywhere via path traversal, trigger an open redirect and export the template unprotected. Blocks every GUEST call of this dispatcher on the front end; logged-in template/menu editing runs behind auth and is NOT affected (guest scope + waf_only, FP-free). Fix: Helix Ultimate 2.2.7 (2026-07-07). Separate product - NOT Helix3.com_ajax: file inclusion (generic) everyone (incl. logged in)Catches unknown LFI holes of the same class: com_ajax with task=include/require. Frontend.SP Page Builder: unauthenticated icon upload (RCE) guests onlyZero-day in SP Page Builder up to 6.6.1: the asset controller (task=asset.uploadCustomIcon) had no access/login check - unauthenticated file upload to /media/com_sppagebuilder/assets/iconfont/ - RCE. Mini-WAF only (guests), since logged-in builders use the endpoint legitimately.DPCalendar: unauth SQL injection (author filter) guests onlyDPCalendar blind SQLi (Joomla 4.4-6 < 10.11.2, J3 < 8.19.4): the front-end author filter filter_created_by (option=com_dpcalendar, view=events) flowed uncast into a.created_by IN (...) in its scalar form - anonymous read of arbitrary DB tables (read-only). Blocks guest requests whose filter_created_by is not a pure integer (legit = author IDs/digits) -> FP-free. Fix 10.11.2 / 8.19.4.AcyMailing: unauth SQL injection (entity-select column list) guests onlyCVE-2026-56292 (AcyMailing 6.0.0-10.11.0): the front-end endpoint EntitySelectController::loadEntityFront (option=com_acym, task=loadEntityFront) placed the request parameters columns/join_table unchecked into the SELECT column list of UserClass::getMatchingElements - an anonymous visitor could read arbitrary DB tables (incl. password hashes) via a subquery. Blocks GUEST calls of this task whose columns/join_table/join value contains an injection character (parenthesis or space) - legitimate values are plain column names (email,name,id ...) and never contain those. Logged-in backend use runs behind auth (guest scope) and is NOT affected. Fix: AcyMailing 10.11.1 (2026-07-09). Matches on GET (scanners/mass exploits); full protection only with the update.Quix Page Builder: unauth SQL injection (single-article AJAX) guests onlyQuix (ThemeXpert, Free AND Pro) up to 6.2.0, incl. the 5.x line: the public AJAX endpoint (option=com_quix, task=ajax, element=joomla-article) calls QuixJoomlaArticleElement::getAjax() with no login/token/license check; the article id arrives base64-encoded in the data parameter and is concatenated UNCAST into the DB query in articleExist() -> unauthenticated error-based SQL injection (CVSS 8.7). Because the payload is base64-encoded (invisible to a regex), the vulnerable endpoint is blocked for GUESTS: published pages render the element server-side (no guest AJAX), the builder runs logged in -> guest scope, FP-free. The legitimate contact-form endpoint (element=simple-contact) and the list-article element (joomla-articles, core model) are NOT affected. Fix: Quix 6.2.1.JoomCCK: unauth SQL injection (tag management) guests onlyCVE-2026-49048 (JoomCCK 6.x before 6.4.1): the front-end task tags.save/tags.delete (option=com_joomcck) ran with NO token/login/permission check and concatenated the request parameter tag (getString) raw - with a double-quote breakout - into TWO consecutive SQL statements (existence SELECT + UPDATE). An anonymous visitor could read and modify the database (stacked/error-based SQLi). Blocks every GUEST call of this admin-only task (no guest manages tags); logged-in tag management runs behind auth and is NOT affected - guest scope + waf_only, FP-free (no payload matching needed, hence independent of the free-text tag). Fix: JoomCCK 6.4.1 (db-quote + token/admin ACL).Path traversal (encoded variants) everyone (incl. logged in)Extends the standard filter with bypass tricks: ....// , double encoding (%252e), %c0%ae, %2e%2e%5c.PHP stream wrapper in the path everyone (incl. logged in)Blocks php:// , phar:// , data:// , expect:// etc. directly in the requested path.Joomla API configuration leak everyone (incl. logged in)CVE-2023-23752: protects the /api/.../v1/config/application endpoint even without a complete API block.PHP object injection (serialised payload) everyone (incl. logged in)Serialised PHP object in a parameter (O:/C:<length>:) - typical entry point for object injection/POP chains. Does not occur in normal requests.PHP stream wrapper in a parameter everyone (incl. logged in)php:// , phar:// , data:// etc. as a parameter value - LFI/RCE vector. Complements the path variant (php-wrapper-uri).Path traversal in a parameter everyone (incl. logged in)Repeated ../ as a parameter value - generic directory traversal/LFI in any component.

The real-time WAF blocks „everyone“ patterns for logged-in/newly registered users too (no legitimate call exists); „guests only“ patterns could be used legitimately and therefore only affect non-logged-in visitors. Super users are never blocked. Query-string signatures cannot be simulated in the path test, path-based ones can.

Upload folder hardening

Additionally places its own mini .htaccess in upload/system folders (images, media, tmp, cache ...) that blocks PHP execution there. This works even if an attacker deletes the main .htaccess – and against unknown future upload holes.

On/off is above under „Most important settings“. Applied automatically on writing.

Folders to harden (one per line, relative to the Joomla root)

Folders under a PHP exception are skipped automatically. Current status below after saving.

File shield

PHP shield: PHP only via allowed entry pointsEverything except index.php (site, /administrator, /api) and the exceptions below is rejected with 403 - including tricks like file.php.jpg.File type shield: deliver only allowed extensionsApplies only to files that actually exist; SEF URLs are untouched.Allowed file extensions (comma separated)

Allow individual files directly (one per line, relative to the Joomla root; also .php)

The Joomla update endpoints (extract.php/restore.php of com_joomlaupdate) are permanently allowed and need not be listed here – core updates always work.

Allow folders completely, including PHP execution (one per line)

Allow folders for all file types, without PHP (one per line)

Completely blocked internal directories (one per line)

Trusted paths (allow everywhere) (one per line)

Stronger than the access rules above: for these paths it also lifts directory locks and exploit signatures (but not the query-string injection filters). Use only for provably harmless paths you have checked yourself. The Akeeba Panopticon connector is included out of the box.

Block internal directoriesBlocks the list above (cache, logs, CLI, tmp ...) completely for web access.Block hidden files (.git, .env, .htpasswd ...)Keep .well-known openNeeded for Let’s Encrypt certificates and app associations.Block sensitive filesconfiguration.php, backup/key/database files, logs, composer.json and much more.Block extension manifests (.xml) (optional, off by default)Hides e.g. plugins/system/jce/jce.xml – otherwise it reveals the installed version (fingerprinting). sitemap.xml & co. in the web root stay reachable. Before enabling, check that no component needs its own .xml directly over HTTP.

Delivery & caching

Compress text content (Brotli/Deflate)Browser cache for static content (Expires)HTML/JSON/XML deliberately stay uncached.Disable ETagsUseful behind load balancers/CDN.

Custom rules

These rules belong permanently to the configuration and are re-embedded into the file on every write – manual changes directly in the .htaccess, on the other hand, are lost on the next write.

At the start of the file

At the end of the file

Manage .htaccess externally

The main .htaccess is managed externally – don't let HTProtect write/monitor itEnable this if you maintain the main .htaccess yourself or via another tool (e.g. Akeeba Admin Tools Pro „.htaccess Maker“). HTProtect then no longer generates, changes or monitors the main .htaccess and does not nag – so the security traffic light stays green. The real-time plugin (exploit shield), malware scan, backend access protection and extension updates keep working unchanged.

Protection works on Apache and LiteSpeed servers (mod_rewrite). Before every write a backup is made automatically; a self-test with auto rollback catches server incompatibilities. Donate