<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Security on Daffa Abhipraya</title><link>https://blog.abhipraya.dev/tags/security/</link><description>Recent content in Security on Daffa Abhipraya</description><generator>Hugo</generator><language>en-us</language><copyright>© Daffa Abhipraya</copyright><lastBuildDate>Wed, 15 Apr 2026 00:00:00 +0700</lastBuildDate><atom:link href="https://blog.abhipraya.dev/tags/security/index.xml" rel="self" type="application/rss+xml"/><item><title>PPL: Security, From App Code to Supply Chain [Sprint 2, Week 3]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w3-security/</link><pubDate>Wed, 15 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w3-security/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>Two weeks of security work that span the whole stack. Week 1 (2-8 Apr) closed two OWASP A01 (Broken Access Control) gaps — one in our own code, one caught during a teammate&amp;rsquo;s code review — and added Sentry observability to Celery tasks so background job failures stop disappearing silently. Week 2 (9-15 Apr) patched a high-severity axios SSRF (GHSA-3p68-rc4w-qgx5) that &lt;code>pnpm audit&lt;/code> caught in a routine MR pipeline. The pattern across the two weeks: fix boundaries in our own code, and keep dependencies patched via automated audit.&lt;/p></description></item><item><title>PPL: Quality Gates That Actually Block Bad Code</title><link>https://blog.abhipraya.dev/ppl/part-a/qa/</link><pubDate>Thu, 09 Apr 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-a/qa/</guid><description>&lt;p>Quality tools are useless if they are not enforced. Our project had SonarQube analyzing every commit, schema fuzzing running against our API, and load tests measuring latency, but every single one of them was set to &lt;code>allow_failure: true&lt;/code>. Violations were silently ignored, real bugs slipped through, and nobody noticed because the pipeline was always green. This blog covers how we turned those advisory checks into blocking gates, built automated CI reporting so reviewers could actually see the results, and watched the tools catch a JWT vulnerability, a production crash, and 31 code quality violations that had been accumulating for weeks.&lt;/p></description></item><item><title>PPL: Security [Sprint 2, Week 2]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w2-security/</link><pubDate>Mon, 30 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w2-security/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>Two security-relevant features merged this week that directly address OWASP Top 10 vulnerabilities: blocking inactive accounts from authenticating (SIRA-215) and enforcing session limits with proper invalidation (SIRA-214). SAST results are now also surfaced automatically on every MR via the CI report system.&lt;/p>
&lt;hr>
&lt;h2 id="owasp-a07-authentication-failures">
 &lt;a class="anchor" href="#owasp-a07-authentication-failures" data-anchor="owasp-a07-authentication-failures" aria-hidden="true">#&lt;/a>
 OWASP A07: Authentication Failures
&lt;/h2>
&lt;p>OWASP A07 covers broken authentication, including cases where deactivated or suspended accounts can still access the system. Before SIRA-215 (MR !104), deactivating a user in the admin panel only prevented login via the UI — a valid JWT issued before deactivation still passed every auth check.&lt;/p></description></item><item><title>PPL: Fixing a JWT Vulnerability [Sprint 2, Week 1]</title><link>https://blog.abhipraya.dev/ppl/part-b/s2w1-security/</link><pubDate>Mon, 23 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s2w1-security/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week I addressed a critical security vulnerability flagged by SonarQube and hardened the CI pipeline so security issues block merges instead of being silently reported.&lt;/p>
&lt;h2 id="the-jwt-vulnerability-sonarqube-s5659">
 &lt;a class="anchor" href="#the-jwt-vulnerability-sonarqube-s5659" data-anchor="the-jwt-vulnerability-sonarqube-s5659" aria-hidden="true">#&lt;/a>
 The JWT Vulnerability (SonarQube S5659)
&lt;/h2>
&lt;p>SonarQube flagged &lt;code>dependencies.py:34&lt;/code> as a &lt;strong>CRITICAL vulnerability&lt;/strong>: &lt;code>jwt.get_unverified_header()&lt;/code> reads the JWT header without verifying the signature. This enables the &lt;strong>alg:none attack&lt;/strong>, where an attacker crafts a token with &lt;code>&amp;quot;alg&amp;quot;: &amp;quot;none&amp;quot;&lt;/code> in the header, causing the library to skip signature verification entirely.&lt;/p></description></item><item><title>PPL: Security [Sprint 1, Week 3]</title><link>https://blog.abhipraya.dev/ppl/part-b/s1w3-security/</link><pubDate>Fri, 13 Mar 2026 00:00:00 +0700</pubDate><guid>https://blog.abhipraya.dev/ppl/part-b/s1w3-security/</guid><description>&lt;h2 id="what-i-worked-on">
 &lt;a class="anchor" href="#what-i-worked-on" data-anchor="what-i-worked-on" aria-hidden="true">#&lt;/a>
 What I Worked On
&lt;/h2>
&lt;p>This week addressed four security areas: JWT algorithm validation hardening (reviewed MR !63), encryption key management in CI (MR !68), client PII encryption in the database seeder (reviewed MR !80), and ongoing SAST scanning via the CI pipeline.&lt;/p>
&lt;h2 id="jwt-algorithm-validation-preventing-algnone-attacks">
 &lt;a class="anchor" href="#jwt-algorithm-validation-preventing-algnone-attacks" data-anchor="jwt-algorithm-validation-preventing-algnone-attacks" aria-hidden="true">#&lt;/a>
 JWT Algorithm Validation: Preventing alg:none Attacks
&lt;/h2>
&lt;p>MR !63 (by adipppp, which I reviewed) hardened the JWT decoding logic against the &lt;strong>alg:none attack&lt;/strong>, one of the most well-known JWT vulnerabilities (OWASP A07:2021, Identification and Authentication Failures).&lt;/p></description></item></channel></rss>