<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>OWASP A05 on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/owasp-a05/</link>
    <description>Recent content in OWASP A05 on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 14 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/owasp-a05/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CORS Misconfiguration: The Open Door You Didn&#39;t Know About</title>
      <link>https://www.secdev.uk/blog/technology/2026-02-14-cors-misconfiguration/</link>
      <pubDate>Sat, 14 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-02-14-cors-misconfiguration/</guid>
      <description>&lt;p&gt;CORS misconfiguration is one of those vulnerabilities that keeps coming up because most developers don&amp;rsquo;t fully understand what CORS actually does. It&amp;rsquo;s the browser mechanism that controls which websites can make requests to your API. When it&amp;rsquo;s configured correctly, it prevents malicious sites from stealing data through a victim&amp;rsquo;s browser. When it&amp;rsquo;s misconfigured, and this happens constantly based on public bug bounty reports, it effectively disables the Same-Origin Policy, letting any website read authenticated responses from your API. What makes CORS misconfigurations particularly interesting to study is that they&amp;rsquo;re invisible to users, silent in server logs, and trivial to exploit.&lt;/p&gt;</description>
    </item>
    <item>
      <title>XXE Attacks: XML Parsing Gone Wrong</title>
      <link>https://www.secdev.uk/blog/technology/2026-01-31-xxe-attacks/</link>
      <pubDate>Sat, 31 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-01-31-xxe-attacks/</guid>
      <description>&lt;p&gt;XML External Entity injection is one of those vulnerabilities that fascinated me the more I dug into it. The core issue is that the XML spec supports external entities, a feature that lets XML documents pull in content from external sources, and most parsers enable this by default. When an app parses untrusted XML without disabling that feature, an attacker can read arbitrary files off the server, perform SSRF, and sometimes even get remote code execution. What surprised me most when researching this was how straightforward the exploitation is compared to how long these bugs survive in production, the attack payloads are simple, but the parser defaults are so permissive that developers often have no idea the risk exists.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Security Misconfiguration</title>
      <link>https://www.secdev.uk/blog/technology/2025-03-29-security-misconfiguration/</link>
      <pubDate>Sat, 29 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-03-29-security-misconfiguration/</guid>
      <description>&lt;p&gt;Security misconfiguration is the vulnerability class that really drove home for me why secure defaults matter more than secure documentation. OWASP A05 covers the gap between what a framework &lt;em&gt;can&lt;/em&gt; do securely and how developers actually configure it. Debug mode left on in production. CORS wide open. XML parsers that resolve external entities. Settings endpoints with no authentication. These aren&amp;rsquo;t coding mistakes, they&amp;rsquo;re configuration mistakes, and they show up everywhere. In this post I&amp;rsquo;ll walk through Python, Java, Go, and JavaScript examples covering CWE-16 (Improper Configuration) and CWE-611 (XML External Entity Processing), from the flags that any reviewer would catch to the subtle combinations that can survive months in production.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
