403 Forbidden when saving settings (Hostinger)

I have asked.

For security reasons, Hostinger does not expose the exact mod_security or WAF rule being triggered to end users. This means they cannot provide the specific rule ID, pattern, or condition that caused the block.

This is all I get from them:

• POST request returns 403 Forbidden error. The POST request to /wp-admin/edit.php?post_type=event&page=events-manager-options is blocked by the server before PHP or WordPress code is executed.
• Issue persists with CDN disabled and no security plugins active. Disabling CDN does not resolve the issue. Other plugins and WordPress core settings save correctly.
• Only Events Manager plugin is affected. All other plugins and WordPress core settings function normally; the problem is isolated to Events Manager.
• Server environment details: Hostinger’s shared hosting environment uses mod_security and other WAF protections. The block likely relates to the structure or payload of the POST request made by the plugin when saving settings.

Any idea?

There are at least 3 other requests describing the same issue:

• https://ww.wp.xz.cn/support/topic/forbidden-67/
• https://ww.wp.xz.cn/support/topic/forbidden-66/
• https://ww.wp.xz.cn/support/topic/error-forbidden-you-dont-have-permission-to-access-this-resource-2/

• This reply was modified 8 months ago by hakuna4matata.

Thanks, this helped. Here’s what I found.

These six fields in the Events Manager (default!) settings consistently trigger a 403:

dbem_calendar_preview_modal_event_format dbem_calendar_preview_modal_date_format dbem_calendar_preview_tooltip_event_format dbem_event_list_item_format dbem_event_grid_item_format dbem_single_event_format

What exactly triggers the WAF

1. Inline style attribute with CSS variable

<div class="em-event em-item" style="--default-border:#_CATEGORYCOLOR;">

The WAF sees style= plus a colon and a hash (#) and assumes it’s a potential XSS (cross-site scripting) attempt. This is the main cause of the 403.

2. Icon spans using two classes with “icon”

<span class="em-icon-clock em-icon"></span>

When both class names contain the word “icon”, some WAF rule sets flag it as “possible HTML/JS injection” (it’s a false positive, but reproducible). Using only one class like em-icon-clock works fine.

It’s a false-positive WAF block caused mainly by the inline style attribute and, in some cases, by <span> elements with multiple “icon” classes.

Following this, I can save my adjusted template without issues – but if I click “Reset to Default”, the default content (which includes those patterns) immediately triggers the WAF again.

Maybe the default template could be updated to use a safer version that avoids inline styles and duplicate “icon” classes.

Hope, it helps.

Additional suggestion:
These template fields are only visible and editable when Advanced Mode is enabled.
It might be safer if those fields were simply excluded from the POST payload when Advanced Mode is disabled – and if the description included a short warning that certain hosts’ WAF systems may block saving because of inline styles or icon markup.

• This reply was modified 8 months ago by hakuna4matata.