ModSecurity and RSS Feeds: Fix False Positives Safely

Short answer: A web application firewall such as ModSecurity with the OWASP Core Rule Set can block feed readers and auto-posters because they send plain requests without the headers that browsers send. To fix it without switching protection off, find the blocked request in the audit log, read which rule fired, add a narrow exclusion that applies only to the feed path and only to the rules that caused the block, keep every other rule active for that path, test with detection-only mode before enforcing a change and confirm the result with curl using a user agent like a feed tool and, separately, with none at all. Then connect the feed address to an auto-poster so that every new article reaches your social channels.

A web application firewall sits in front of your site and inspects every request for signs of attack. It is a valuable layer, especially for sites that run common content management systems with many plugins. The Core Rule Set that most installations use assigns points to suspicious features of a request, adds them up and blocks the request when the total passes a threshold. Feed tools have several features that earn points. They often send no Accept-Language header, a short or unusual user agent such as the name of a programming library, no cookies and a very regular rhythm. None of that is an attack, but a rule written to catch scanners does not know the difference. The result is a feed that works for you in a browser and returns a 403 status to the tools that matter. This guide explains how to find the rule that fired, how to write a safe exclusion and how to keep the firewall strong everywhere else. Rule numbers and directive details change between versions, so check them against your own logs and documentation.

How a firewall scores a feed request

The Core Rule Set works with anomaly scoring. Each rule that matches adds a score, depending on its severity. When the request finishes the inspection phase, the total is compared with a threshold, and the request is blocked if the total is high enough. A single critical match is often enough, because its score equals the default threshold. This design means that a request can be blocked by one rule you never heard of, or by several small matches that add up. For a feed, the usual causes are a rule about the user agent, one about missing headers and one about the request being made by an automated client. The table lists typical situations. Do not rely on the numbers in the table without checking them in your log, because they differ between versions and local settings.

Step 1: find the blocked request

Start from the facts. When a tool reports that the feed is forbidden, look for the same time in the audit log of the firewall, which records the full request and the rules that matched. The location depends on your set-up, and a common one is a file in the system log folder. The error log of the web server also records the matches, with the rule number and a message.

sudo grep -i "feed" /var/log/modsec_audit.log | tail -5
sudo grep -E "id \"9[0-9]{5}\"" /var/log/nginx/error.log | tail -20

Look for the entries that mention the feed path and note three things: the numbers of the rules that matched, the messages that describe them and the total anomaly score. A message about a missing header or a scripting client tells you immediately what the tool did that the rule disliked. If you cannot find any entry, the block may come from another layer, such as a content delivery network or a firewall at the hosting provider, and you should check those, as described in the guide to blocked feeds.

Step 2: try detection-only mode for a change

Never test a change by turning off the whole firewall in production, and avoid changing rules on a live site without a plan. ModSecurity has a mode in which it logs what it would block without blocking anything. Use it on a test site, or temporarily on the live site for a short window with a note of the time, to watch what a new rule or a new exclusion does.

SecRuleEngine DetectionOnly

Switch back to the enforcing mode as soon as you have the information you need. A firewall left in detection mode and forgotten gives a false sense of security. Keep a record of every change with the date and the reason, so that the next person understands why an exclusion exists.

Step 3: write a narrow exclusion for the feed path

The exclusion should do three things: apply only to the feed path, remove only the rules that caused the block and leave everything else active. A runtime exclusion that checks the path is the cleanest form. It must be loaded before the rules it affects, because it works by changing how later rules behave for the current request.

# exclusions loaded before the Core Rule Set
SecRule REQUEST_URI "@beginsWith /feed" "id:10001,phase:1,pass,nolog,ctl:ruleRemoveById=920300,ctl:ruleRemoveById=920320,ctl:ruleRemoveById=913101,ctl:ruleRemoveById=913102"

The rule has its own identifier, runs in the first phase, passes the request on without logging and tells the engine to skip four checks for requests whose path starts with the feed address. Replace the numbers with the ones from your log, not with the examples. If your site has several feeds, list their paths with an operator that accepts a list, or write one rule for each folder. Rules that are removed at configuration time, after the rule set is loaded, are an alternative for a rule that you never want, but they affect the whole site and should be used with care.

Step 4: keep protection on for the path

Do not use an exclusion that turns the engine off for the feed path. A feed address is a read-only resource that accepts only simple requests, so most attack rules never match, but a path that is completely unprotected can still become a route for abuse, for example through crafted query strings. Remove only what is needed. You can also restrict the methods that the path accepts to GET and HEAD, and reject everything else, which is both safe and cheap. If your feed is served by a script, make sure that the script ignores unexpected parameters. The wider topic of feed safety is covered in the guide to feed security.

Step 5: reload and test with realistic requests

Check the configuration, reload the web server and test with requests that look like the tools you use. A request with a normal browser user agent is the easy case. The important tests are a request with the kind of user agent that a feed library sends and a request with no user agent at all, because some tools send nothing.

sudo nginx -t && sudo systemctl reload nginx
curl -sI -A "Mozilla/5.0" https://example.com/feed.xml
curl -sI -A "python-requests/2.31" https://example.com/feed.xml
curl -sI -H 'User-Agent:' https://example.com/feed.xml
curl -sI https://example.com/wp-login.php

• The first three requests return 200 and the RSS content type with a UTF-8 charset.
• The last request is a control: it should still be handled by the normal rules of your site, which proves that protection is intact elsewhere.
• The audit log shows no new block entries for the feed path.
• The address passes the W3C Feed Validation Service without errors.

A longer routine is in the feed validation guide, and a shorter one in debugging a feed with curl.

Other things that look like a firewall problem

Not every 403 comes from ModSecurity. A file that tells crawlers what to avoid does not block a request by itself, but some tools respect it, as explained in the guide to robots.txt and feeds. A banned address, a rate limit or a rule at the hosting provider can produce the same status. A security plugin inside the content management system may block requests with an empty user agent. If your feed passes the firewall test but a tool still fails, ask for the exact status code and the time of the failure and compare it with every log in the chain. The meaning of each status is explained in the guide to feed status codes.

Keep the exclusions healthy

Exclusions are part of your security configuration, and they need the same care as code. Keep them in one file with comments that say what each rule does and when it was added. Review them when you update the rule set, because identifiers and behaviour change, and an old exclusion may refer to a rule that now means something else. After each update, run the feed tests again. Watch for new blocks after a change in the tools that you use, for example when an auto-poster changes the way it identifies itself. A short monthly check of the audit log for feed paths is enough to catch problems before readers do.

Common mistakes to avoid

• Turning the firewall off for the whole site. Exclude only what the feed needs.
• Excluding rules by guesswork. Use the numbers from your own log.
• Loading the exclusion after the rules. A runtime exclusion must come first.
• Forgetting the control test. Prove that other paths stay protected.
• Leaving detection-only mode on. Switch back to enforcing.
• Undocumented exclusions. Write down the reason and the date.

How PostRSS works with a feed behind a firewall

PostRSS has been publishing RSS and Atom feeds to social networks since 2014. Paste the address of your feed, connect your accounts and choose how each post is built from the title, the description or the page title. PostRSS checks the feed as often as every minute and shares each new entry, with its image and link, to the channels you choose among 66 supported networks, messengers, team chats and blogs, including LinkedIn, X, Bluesky, Mastodon and Telegram. Keyword filters, UTM parameters and posting windows let you tune each channel. See the PostRSS features page and the plan limits on the pricing page. More developer guides are under the Technical Guide tag.

Saistīta lasāmviela

• RSS feed security: can someone spoof or hijack your feed?
• RSS feed timeouts: why a slow server breaks auto-posting
• Static RSS feed with a cron script

The bottom line

A firewall that protects your site can also stop the tools that share your articles. Find the blocked request in the audit log, read which rules fired, write a narrow exclusion for the feed path that removes only those rules and loads before the rule set, keep every other protection active, test with detection-only mode before you enforce, check the result with realistic and empty user agents and with a control request to another path, and document the change. Then connect the feed to an auto-poster, so that every article you publish reaches your social channels without being mistaken for an attack.

FAQ

Why does ModSecurity block my RSS feed?

Feed tools often send no Accept-Language header, a library name as the user agent or no user agent at all. Rules written to catch scanners add points for these features, and the request is blocked when the score passes the threshold.

Should I disable the firewall for the feed path?

No. Remove only the rules that caused the block, using the numbers from your own audit log, and keep the other rules active for the path. Limit the methods to GET and HEAD.

Where do I put an exclusion for the Core Rule Set?

A runtime exclusion that uses a control action must be loaded before the rules it affects. An exclusion that removes a rule at configuration time must come after the rule set is loaded.

How can I test without blocking real visitors?

Use detection-only mode on a test site, or for a short and noted window on the live site, and watch what the audit log records. Switch back to enforcing mode when you are done.

Can PostRSS read a feed behind a web application firewall?

Yes. PostRSS reads any valid RSS or Atom address that is reachable without a login. Make sure your rules do not block the tool, paste the address, connect your channels and new articles are shared as soon as they appear.