Attack Protection | SeenSecure Help

🛡️ Multi-Layer Defense Architecture

"Attack Protection" is not a single three-layer module: it is the combination of all defense modules working together in successive layers. Each layer covers the failures of the previous one. None protects alone; together they form real defense in depth.

Layer	What it blocks	Documentation
1. Early Shield (PRO)	Unusual HTTP methods, null bytes, oversized URLs, exploit patterns (path traversal) and sensitive-file access — before WordPress even loads	Early Shield
2. Firewall WAF	Fuzzing, parameter pollution, redirect injection, WAF signatures (3 modes)	Firewall · Modes
3. Anti-Bot (5 layers)	Automated bots, scrapers, headless browsers, fake crawlers, spoofed IPs	Anti-Bot
4. Anti-Injection	SQLi, NoSQL, XSS, LFI/RFI, Command Injection, Deserialization, XXE, LDAP, SSRF, Open Redirect in URLs, forms, cookies and headers	Anti-Injection Shield
5. Redirect Sanitization	Token leakage, API keys and sensitive data in redirect URLs	Sanitization
6. Referer Context	Basic CSRF, critical POSTs without legitimate origin, bots without Referer	RCP
7. Rate Limiting	Brute force, intensive scraping, excessive requests per IP	Rate Limiting
8. Geo-Blocking	Traffic from high-risk countries and geolocated automated flows	Geo-Blocking
9. Upload Protection	PHP shells, executables, fake MIME, double extension, null byte	Uploads
10. Security Headers	Reflected XSS, clickjacking, MIME sniffing, MITM, CSP, SRI	Headers
11. DDoS Resilience	Request saturation and application-level emergency mode	DDoS Resilience
12. Hardening	User enumeration, directory listing, file exposure, APIs	Hardening
13. Protection Network	IPs confirmed by multiple sites (collaborative feed, PRO only)	Network · Threat Intel
14. Login Security + 2FA	Login brute force, CAPTCHA, restricted accounts, second factor	Login · 2FA
15. Scanner + Backups	Malware, vulnerabilities, file integrity and emergency restore	Scanner · Backups

💡 How to read this table: You don't need to enable everything at once. Start with the Firewall in Monitor mode, review logs for 24-48h and gradually move up to Protect. Layers 4, 5 and 6 (anti-injection, sanitization and Referer) are what this page documents in detail.

🔀 Redirect URL Sanitization

Automatically cleans redirect URL parameters to remove sensitive data such as emails, API keys, authentication tokens, passwords, and other confidential information before the user is redirected.

🎯 What it protects

Information Disclosure: Prevents sensitive data from appearing in URLs, logs, Referer headers, or browser history.

Token Leakage: Removes API keys, auth tokens, and secrets before redirecting.

Email Harvesting: Removes email addresses exposed in URL parameters.

🧹 Data it removes

▪ Emails:    user@example.com, admin@site.com
▪ API Keys:  ?api_key=abc123, &apikey=xyz789
▪ Tokens:    ?token=secret123, &auth=bearer_token
▪ Passwords: ?password=mypass, &secret=confidential

⚡ Recommended setting: Keep it ENABLED. It is an extra security layer with no impact on functionality. It only cleans URLs when redirecting, without affecting normal parameter processing.

🛡️ Anti-Injection Shield (SQL/NoSQL/XSS/LFI/Commands/XXE/SSRF)

Detects and blocks injection attempts in URLs, forms, cookies, and HTTP headers. Acts as a safety net that stops attacks even if some plugin or theme has vulnerabilities. Covers 10 attack classes: SQL Injection, NoSQL Injection, XSS, LFI/RFI, Command Injection, PHP Deserialization, XXE, LDAP Injection, SSRF, and Open Redirect.

Attack types it blocks

SQL Injection

Attempts to read, modify, or delete database data (users, posts, configuration) using special characters like ', --, or UNION in parameters.

NoSQL Injection

Sends NoSQL database operators (such as MongoDB) in a parameter to bypass a login or read data without knowing the password. WordPress uses MySQL, but some plugins store their data in NoSQL databases. Example: ?user[$ne]=x.

XSS

Injects malicious scripts into your site’s pages to steal sessions and cookies, impersonate your users or redirect them to other sites.

LFI / RFI

Tries to load local server files (such as /etc/passwd or wp-config.php) or remote files, to read confidential information or run malicious code. In its advanced variants, an LFI turns into remote code execution (RCE), that is, full control of the server. Example: ?file=../../wp-config.php.

Command Injection

Attempts to run commands on the server's own operating system (not the database) through a parameter, combining special characters (backticks, semicolons, &&, pipes |) with a known command. Example: ?id=1; cat /etc/passwd or ?file=photo.jpg`whoami`. A common variant is injecting PHP code for the same purpose.

Deserialización PHP

Sends a hand-crafted "serialized" PHP object in a parameter, trying to manipulate the site's internal logic when it gets reconstructed (can sometimes lead to code execution). Recognizable by a very distinctive format like O:8:"stdClass":1:{...}.

XXE

Sends an XML document with an "external entity" that tries to make the server read internal files (like /etc/passwd) or contact another server. Recognizable by a <!DOCTYPE> with an <!ENTITY> pointing to file:// or another scheme. Example: <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>.

XML sent in the request body is also checked even when it is declared with another content type (text, JSON or none) or arrives in another encoding (UTF-16), two common tricks to slip past filters. It also covers the “out-of-band” (OOB) variant, where the XML makes your server download a malicious .dtd from the attacker to send the data out another way.

LDAP Injection

Manipulates an LDAP search filter (used by corporate authentication systems) by adding parentheses and operators to bypass validation or extract directory data. Example: *)(uid=*))(|(uid=*.

SSRF

Tries to make the SERVER ITSELF issue an outbound request to an internal or forbidden destination (localhost, the internal network, or the cloud metadata endpoint), usually by passing a URL as a parameter value. Example: ?url=http://169.254.169.254/latest/meta-data/ or ?image=http://127.0.0.1:6379/. Attackers also disguise the internal address to try to go unnoticed.

Open Redirect

Manipulates a redirect parameter (like ?redirect_to=) so that, after a legitimate action (e.g. login), the user ends up on an external site controlled by the attacker — mainly used in phishing campaigns. Example: ?redirect_to=https://malicious-site.com or ?next=//evil.com.

🔍 Where it acts

Inspects traffic at three key points:

URLs and GET/POST parameters: Searches, forms, filters, pages.

Cookies: Especially sessions manipulated with malicious payloads.

HTTP Headers: User-Agent, Referer, and others with injection payloads.

⚙️ Configuration options

Action

Off: detects and logs the same as Monitor, but never blocks (the "Enabled" switch above is what turns detection itself on or off).
Challenge: blocks with a 403 + logs the IP for 2h.
Block: blocks with a 403 + logs the IP for 2h.
Block request only: serves a one-off 403 but does NOT log the IP in "Blocked IPs" — useful while testing the protection or for legitimate traffic behind shared NAT/proxies.
Monitor: only logs, never blocks.

Sensitivity

Low: Only very clear patterns. Minimal false positives.
Medium (recommended): Balance between detection and false positives.
High: Maximum detection. May generate false positives.

Allowlists

Paths: URLs that are not inspected (e.g., /wp-json/, /admin-ajax.php).
Parameters: Parameter names to ignore (e.g., s, paged, rest_route).

💡 Recommendation: Start with Challenge + Medium. If there are false positives, lower the sensitivity or add the exact path to the allowlist. DO NOT add attack payloads to the allowlist.

⚠️ Important if you turn it off: if you switch off this Shield's "Enabled" toggle, SQLi/XSS/LFI/command injection stop being blocked — unless you have the Security Headers toggle enabled (Firewall → Headers), which acts as a fallback engine for those same attacks. If both toggles are off at the same time, those attempts are only logged, not blocked. The panel warns you with a red message on this same tab when it detects that situation.

🏁 Race condition (PRO)

A race-condition attack sends many identical requests at the same time to the same URL to exploit a check that is not atomic: redeeming a coupon several times, validating a code twice or withdrawing balance in parallel. If the server processes them simultaneously, each one passes the “was it already used?” check before any of them marks it as used.

How it is detected: identical POST requests (same IP, same URL and same body) that are still in progress at the same moment. It does not depend on a time window: it counts the ones being processed at once.

What it does: lets only the first one through, discards the rest with a 403 and records each discard in the log as “Race condition” (Traffic Log and Live Monitor), with the number of requests that coincided.

Double click: it also sends two identical requests. The second is discarded and the user gets the result of the first, so it is usually not noticeable.

Where to configure it: Firewall → Attack protection → “Race condition”. It has a switch, the action (“Let only one through and discard the rest”, the default, or “Log only”) and the maximum duration of a request in seconds (default 5). It is a PRO feature.

What it does not do: it does not add the IP to the blocklist, it only covers POST requests and it cannot tell whether the redemption was valid: it only prevents more than one from being processed at once.

🧬 Attack and CVE recognition (PRO)

Every blocked request is analysed to find out what it was trying to do: SQL injection, XSS, remote code execution, user enumeration, and so on. If it also matches a specific signature of a known CVE, the log shows the CVE number.

Confidence levels: “signature” = pattern of the attack category; “probable attempt” = aimed at a sensitive point of the site; “confirmed” = specific signature of a known attack.

It works even when another layer (Anti-Bot, Geo, etc.) stopped the request. The analysis does not claim the attack succeeded: only that it was stopped.

⛔ Auto-block for confirmed CVE (PRO)

Only when a specific signature of a known CVE matches, the IP is added to the permanent blocklist and reported to the SeenSecure Network. It is the only detection that blocks the IP automatically.

Never blocked: legitimate infrastructure (Google, Bing), allowlisted IPs or the site’s own requests.

Generic pattern signatures only classify; they do not block the IP.

⛔ Auto-block for injection (off by default)

An injection pattern (SQLi, XSS, LFI…) always blocks that request with a 403. Adding the IP to the permanent blocklist is a separate option, off by default, because a pattern can appear in legitimate traffic.

Turn it on only if you want to permanently ban whoever repeats injection attempts. The protection never blocks legitimate infrastructure or allowlisted IPs.

Referer Context Protection (RCP)

Validates the origin of HTTP requests using the Referer header. If a critical POST request (login, form submission) lacks a Referer or comes from an unauthorized external domain, it is blocked. It is a lightweight and fast layer that works before the request reaches PHP.

✅ Advantages

🚀 Lightweight and fast: only validates HTTP headers, zero performance impact

🤖 Stops automated bots that rarely send a valid Referer

🛡️ Detects basic CSRF: cross-site requests without a legitimate Referer

🔒 Protects wp-admin against direct access from external domains

⚠️ Considerations

🔍 False positives: browsers/extensions may block the Referer for privacy

🔌 APIs/webhooks must be added to exceptions (e.g., /api/*, /webhook/*)

⚖️ Not 100% security: the Referer can be spoofed, but it stops basic attacks

📋 Recommended implementation

"Log" mode for 24-48h — Identify false positives without blocking anyone.
Review logs and add exceptions — Add /wp-json/*, your APIs, webhooks.
Switch to "Challenge" — Once exceptions are confirmed, enable blocking.
Only use "Block" if 100% sure — No margin for false positives.

💡 Tip: RCP works best combined with the other protections. Use it alongside the Anti-Injection Shield and Redirect Sanitization for defense in depth.

🌐 Protection Network (Feeds)

In addition to the local layers, SeenSecure has its Protection Network: the collaborative component that shares blocks among all PRO clients. When your site blocks an attack, it can report it anonymously to the central service; the server cross-checks reports from all sites and publishes a feed with IPs confirmed by at least two different sites. Your WordPress consumes that feed and blocks in advance IPs that have not yet attacked your site but have already been detected by the community.

🔁 Flow

Your site blocks an attack and reports it anonymously.
The server scores the IP and publishes it if ≥2 sites confirm it.
All PRO clients receive the IP in the feed and block it in advance.

🔒 Privacy

Only evidence of an already executed block is shared. Visitors are not tracked and no personal data is sent; the site's domain is never published in the feed. The feed travels encrypted and IPs are distributed hashed with a daily rotating key plus per-site watermarks (leak detection).

📄 Full documentation

Complete guide to the Protection Network (how to report, consume the feed, GDPR consent, troubleshooting) at Protection Network. Third-party lists (Spamhaus, FireHOL, blocklist.de) are explained at Threat Intelligence.

⚠️ Requirement: The Network feed is only delivered to PRO licenses (or trial) with active reporting and explicit administrator consent (Art. 6.1.a GDPR). Without a PRO license, your site remains protected by all the local layers on this page.

🏗️ Architecture

The defense is organized into five levels, each with several layers:

1️⃣ Network Level

IP filtering, geo-blocking, allow/block lists, Protection Network feed and Threat Intelligence.

2️⃣ Application Level

WAF rules, anti-injection, redirect sanitization, Referer Context, rate limiting and anti-bot.

3️⃣ File System Level

Upload protection, integrity monitoring, malware detection and critical file protection.

4️⃣ User Level

Login security (brute force, CAPTCHA), 2FA and restricted account management.

5️⃣ Data Level

Database security, backups and emergency restore.

💡 Before PHP: The Early Shield, Referer Context and early rate limiting capture layers run BEFORE WordPress loads (at file level), so that even an attack that saturates PHP loading cannot disable them.

⚡ Performance

The attack layers are designed to have minimal impact:

✅ No noticeable cost

Redirect sanitization and Referer Context only inspect headers/strings: microseconds, zero extra database queries.

✅ Caching and in-memory lists

The Network blocklist is cached in memory (at most one option read per request), and WAF signatures are compiled only once.

✅ Asynchronous processing

Network reports are queued and sent in batches (cron), never during the visitor's request.

🔧 Troubleshooting

🚫 It blocks me / a user

1) Check Monitoring → Traffic for the exact reason (anti_injection, referer_context, rate_limiting…).
2) If Referer: add the path or domain to exceptions.
3) If anti-injection: lower sensitivity or add the parameter/path to the allowlist.
4) Add your IP to the allowlist (IP Lists) while tuning.
5) Use Emergency Mode only if you lose total access.

🔌 My API/webhook fails

Add the path to Referer Context exceptions (/api/*, /webhook/*) and to the anti-injection allowlists. Payments (WooCommerce, PayPal, Stripe) are protected by default without breaking checkout.

❌ The Network feed says 0 / won't sync

1) Confirm active PRO license and reporting enabled with consent.
2) Press "Sync" in the Protection Network tab.
3) IPs only appear once the server publishes them (≥2 sites). Your own report appears as "own IP" (counts as blocked by your site even before publication).
4) Check the ssc_log log if fetching fails.

⚠️ Golden rule: Before disabling a protection, open its tab, look at the latest blocks and adjust the configuration (sensitivity, allowlists, exceptions). Disabling all protection "because it's annoying" is exactly what an attacker hopes for.

⭐ Best Practices

Raise the mode gradually: Monitor → Challenge → Block. Never jump straight to Block in production without reviewing logs.
Keep the "frictionless" layers on: redirect sanitization, anti-injection in Challenge, security headers and basic anti-bot.
Use allowlists, not disablement: if something legitimate gets blocked, add it to the allowlist. Disabling a layer makes it useless for real attacks too.
Enable the Protection Network (PRO): report and consume the collaborative feed: the more sites contribute, the faster and more accurate the blocklist is for everyone.
Review the dashboard weekly: layer badges, recent blocks and Network reports tell you if something needs tuning.
Combine with hardening and 2FA: defense in depth is completed with site hardening and a second factor on all admins.

🎯 Bottom line: With all layers active and the Protection Network connected, your WordPress stops attacks your site has never seen, without relying on a single line of defense.