<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: AuthVolt</title>
    <description>The latest articles on Forem by AuthVolt (@authvolt).</description>
    <link>https://forem.com/authvolt</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3872186%2F10d21cb9-12c0-4dc8-ba5b-515435e785fe.png</url>
      <title>Forem: AuthVolt</title>
      <link>https://forem.com/authvolt</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/authvolt"/>
    <language>en</language>
    <item>
      <title>How I built a 7-layer security stack for a software licensing API</title>
      <dc:creator>AuthVolt</dc:creator>
      <pubDate>Fri, 10 Apr 2026 17:00:34 +0000</pubDate>
      <link>https://forem.com/authvolt/how-i-built-a-7-layer-security-stack-for-a-software-licensing-api-30ah</link>
      <guid>https://forem.com/authvolt/how-i-built-a-7-layer-security-stack-for-a-software-licensing-api-30ah</guid>
      <description>&lt;p&gt;How I built a 7-layer security stack for a software licensing API&lt;/p&gt;

&lt;h2&gt;
  
  
  The Problem
&lt;/h2&gt;

&lt;p&gt;If you build desktop software and sell it, you need a way to verify that the person running your app actually paid for it. The typical solution: license keys + an API that validates them.&lt;/p&gt;

&lt;p&gt;But a simple "check key against database" endpoint gets cracked in hours. Replay attacks, shared keys, spoofed hardware IDs, brute-force attempts — the attack surface is massive.&lt;/p&gt;

&lt;p&gt;I needed something better. So I built AuthVolt (&lt;a href="https://authvolt.net" rel="noopener noreferrer"&gt;https://authvolt.net&lt;/a&gt;) with 7 independent security layers that every API request must pass through.&lt;/p&gt;

&lt;h2&gt;
  
  
  The Architecture
&lt;/h2&gt;

&lt;h3&gt;
  
  
  Layer 1: Perimeter Firewall
&lt;/h3&gt;

&lt;p&gt;Before any application code runs, incoming requests are checked against:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Blocked IP addresses and CIDR ranges&lt;/li&gt;
&lt;li&gt;Country-level geo-blocking&lt;/li&gt;
&lt;li&gt;Banned user-agent patterns&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This is pure filtering — no business logic, no database queries. Malicious traffic is dropped at the edge.&lt;/p&gt;

&lt;h3&gt;
  
  
  Layer 2: Adaptive Rate Limiting
&lt;/h3&gt;

&lt;p&gt;Every action has its own rate limit bucket, keyed by &lt;code&gt;IP + action_type&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;Why per-action? Because a failed login attempt shouldn't block the same IP from registering. And a registration shouldn't affect API authentication requests.&lt;/p&gt;

&lt;p&gt;Progressive throttling: first offenses get slowed down, repeat offenders get temporary bans.&lt;/p&gt;

&lt;h3&gt;
  
  
  Layer 3: Bot Detection
&lt;/h3&gt;

&lt;p&gt;Automated scripts, headless browsers, and credential-stuffing tools are identified by behavioral patterns. Suspicious requests are challenged (CAPTCHA or math verification) before reaching any auth logic.&lt;/p&gt;

&lt;h3&gt;
  
  
  Layer 4: Deep Payload Inspection
&lt;/h3&gt;

&lt;p&gt;Every request body is analyzed across 16+ attack categories:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;SQL injection patterns&lt;/li&gt;
&lt;li&gt;XSS payloads&lt;/li&gt;
&lt;li&gt;Path traversal attempts&lt;/li&gt;
&lt;li&gt;Deserialization exploits&lt;/li&gt;
&lt;li&gt;Command injection&lt;/li&gt;
&lt;li&gt;And more&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This runs on every request, not just auth endpoints.&lt;/p&gt;

&lt;h3&gt;
  
  
  Layer 5: HWID Verification
&lt;/h3&gt;

&lt;p&gt;License keys are bound to a cryptographic hardware fingerprint. The client app collects hardware identifiers (CPU, motherboard, disk serial, etc.), hashes them, and sends the HWID with every auth request.&lt;/p&gt;

&lt;p&gt;If the HWID doesn't match what's registered — the key is rejected instantly. Shared keys become worthless.&lt;/p&gt;

&lt;h3&gt;
  
  
  Layer 6: Endpoint Hardening (Enterprise)
&lt;/h3&gt;

&lt;p&gt;Enterprise-tier endpoints use:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Custom URL paths (no standard &lt;code&gt;/api/auth&lt;/code&gt; to discover)&lt;/li&gt;
&lt;li&gt;Dynamic routing that changes on configuration&lt;/li&gt;
&lt;li&gt;Response encryption&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Static analysis of the binary won't reveal the endpoint. Packet sniffing won't reveal the response format.&lt;/p&gt;

&lt;h3&gt;
  
  
  Layer 7: Continuous Monitoring
&lt;/h3&gt;

&lt;p&gt;Every authentication event is logged with:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Timestamp, IP, user-agent&lt;/li&gt;
&lt;li&gt;HWID fingerprint&lt;/li&gt;
&lt;li&gt;License key used&lt;/li&gt;
&lt;li&gt;Result (success/fail/blocked)&lt;/li&gt;
&lt;li&gt;Which security layer rejected it (if applicable)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Anomalous patterns trigger alerts. If one key suddenly authenticates from 50 different IPs — you know immediately.&lt;/p&gt;

&lt;h2&gt;
  
  
  Key Security Decisions
&lt;/h2&gt;

&lt;p&gt;&lt;strong&gt;Anti-timing attacks on login:&lt;/strong&gt;&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight php"&gt;&lt;code&gt;&lt;span class="c1"&gt;// Even if user doesn't exist, run password_verify against a dummy hash&lt;/span&gt;
&lt;span class="c1"&gt;// This prevents timing-based username enumeration&lt;/span&gt;
&lt;span class="k"&gt;if&lt;/span&gt; &lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="o"&gt;!&lt;/span&gt;&lt;span class="nv"&gt;$user&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
    &lt;span class="nb"&gt;password_verify&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nv"&gt;$password&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="s1"&gt;'$2y$12$dummy.hash.here'&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
    &lt;span class="k"&gt;return&lt;/span&gt; &lt;span class="kc"&gt;false&lt;/span&gt;&lt;span class="p"&gt;;&lt;/span&gt;
&lt;span class="p"&gt;}&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;&lt;strong&gt;Per-account lockout with sliding window:&lt;/strong&gt;&lt;br&gt;
Instead of permanent lockouts (which become a DoS vector), I use a 30-minute sliding window. 5 failed attempts in 30 minutes = temporary lock. Window resets naturally.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Constant-time token comparison:&lt;/strong&gt;&lt;br&gt;
All CSRF and session token comparisons use &lt;code&gt;hash_equals()&lt;/code&gt; — never &lt;code&gt;===&lt;/code&gt; or &lt;code&gt;strcmp()&lt;/code&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  Results
&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;Auth latency: &amp;lt;50ms per request&lt;/li&gt;
&lt;li&gt;Zero framework dependencies (pure PHP 8 + MySQL)&lt;/li&gt;
&lt;li&gt;Runs on any standard hosting&lt;/li&gt;
&lt;li&gt;Full admin panel with 30+ management pages&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The platform is live at &lt;a href="https://authvolt.net" rel="noopener noreferrer"&gt;https://authvolt.net&lt;/a&gt; with a free tier if you want to see it in action.&lt;/p&gt;




&lt;p&gt;What security measures would you add? What do you think is overkill? I'd love to hear from developers who've dealt with similar problems.&lt;/p&gt;

</description>
      <category>security</category>
      <category>php</category>
      <category>api</category>
      <category>webdev</category>
    </item>
  </channel>
</rss>
