<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Waf on BareProxy.com</title>
    <link>https://bareproxy.com/tags/waf/</link>
    <description>Recent content in Waf on BareProxy.com</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 08 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://bareproxy.com/tags/waf/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>BareProxy Rate Limiting and WAF Plugin: Per-Address Limits and Bad-Request Rules at the Edge</title>
      <link>https://bareproxy.com/bareproxy-rate-limiting-and-waf-plugin-per-address-limits-and-bad-request-rules-at-the-edge/</link>
      <pubDate>Thu, 08 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://bareproxy.com/bareproxy-rate-limiting-and-waf-plugin-per-address-limits-and-bad-request-rules-at-the-edge/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Status: planned, number 8 of 21 in BareProxy&amp;rsquo;s build order.&lt;/strong&gt; The plugins are built easiest first, and this one is about a day of coding: counters in shared data and simple rules. It comes after the A/B and canary splits plugin. This post describes what it will do, and it will be updated as it is built.&lt;/p&gt;&#xA;&lt;p&gt;Two of the oldest reasons to put a proxy in front of an app are to stop one client from taking all of it, and to turn away requests that are obviously up to no good before the app has to look at them. Most small apps handle neither. A login form that takes a thousand guesses a minute, or a search endpoint hammered by a script, can take a site down long before anyone notices an attack.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
