<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Web Security on Njeru Mtwaiti</title>
    <link>https://blog.njerumtwaiti.com/categories/web-security/</link>
    <description>Recent content in Web Security on Njeru Mtwaiti</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Tue, 12 Aug 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://blog.njerumtwaiti.com/categories/web-security/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Fintech API Security: The Attack Surfaces Nobody Talks About</title>
      <link>https://blog.njerumtwaiti.com/posts/fintech-api-security-attack-surfaces/</link>
      <pubDate>Tue, 12 Aug 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.njerumtwaiti.com/posts/fintech-api-security-attack-surfaces/</guid>
      <description>&lt;p&gt;Working in fintech security — both building payment infrastructure at Durrafx and testing external platforms through bug bounty — has given me a particular view of how fintech APIs fail. The standard OWASP Top 10 checklist catches the obvious stuff. This post is about what comes after that.&lt;/p&gt;&#xA;&lt;h2 id=&#34;why-fintech-apis-are-different&#34;&gt;&#xA;  Why Fintech APIs Are Different&#xA;  &lt;a class=&#34;heading-link&#34; href=&#34;#why-fintech-apis-are-different&#34;&gt;&#xA;    &lt;i class=&#34;fa-solid fa-link&#34; aria-hidden=&#34;true&#34; title=&#34;Link to heading&#34;&gt;&lt;/i&gt;&#xA;    &lt;span class=&#34;sr-only&#34;&gt;Link to heading&lt;/span&gt;&#xA;  &lt;/a&gt;&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;A generic web app leaking user data is bad. A payment API leaking transaction data, processing unauthorized disbursements, or allowing account takeover is directly money-out-the-door bad. The stakes mean that subtle logic flaws — the kind that don&amp;rsquo;t trigger a WAF, don&amp;rsquo;t show up in automated scans, and require understanding the business model — are often the most valuable findings.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SQL Injection from Zero to Shell: A Practical Walkthrough</title>
      <link>https://blog.njerumtwaiti.com/posts/sql-injection-zero-to-shell/</link>
      <pubDate>Mon, 10 Feb 2025 00:00:00 +0000</pubDate>
      <guid>https://blog.njerumtwaiti.com/posts/sql-injection-zero-to-shell/</guid>
      <description>&lt;p&gt;SQL injection is one of the oldest and most consistently exploited vulnerability classes on the web. It&amp;rsquo;s been in the OWASP Top 10 since 2003. It keeps showing up in real engagements, bug bounty reports, and CTF challenges year after year.&lt;/p&gt;&#xA;&lt;p&gt;This post walks through SQL injection end-to-end — detection, manual exploitation, data extraction, and in some cases, a path to remote code execution.&lt;/p&gt;&#xA;&lt;h2 id=&#34;how-it-works&#34;&gt;&#xA;  How It Works&#xA;  &lt;a class=&#34;heading-link&#34; href=&#34;#how-it-works&#34;&gt;&#xA;    &lt;i class=&#34;fa-solid fa-link&#34; aria-hidden=&#34;true&#34; title=&#34;Link to heading&#34;&gt;&lt;/i&gt;&#xA;    &lt;span class=&#34;sr-only&#34;&gt;Link to heading&lt;/span&gt;&#xA;  &lt;/a&gt;&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;When a web application constructs a SQL query by directly embedding user input, an attacker can manipulate that query&amp;rsquo;s logic.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
