<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>CWE-639 on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/cwe-639/</link>
    <description>Recent content in CWE-639 on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 15 Feb 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/cwe-639/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Broken Access Control</title>
      <link>https://www.secdev.uk/blog/technology/2025-02-15-broken-access-control/</link>
      <pubDate>Sat, 15 Feb 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-02-15-broken-access-control/</guid>
      <description>&lt;p&gt;Broken access control sits at the top of the OWASP Top 10 for good reason, and it&amp;rsquo;s the vulnerability class I find most fascinating to research. It&amp;rsquo;s the most common serious vulnerability in modern web applications, and it&amp;rsquo;s almost entirely a logic problem, no amount of input sanitization or encryption fixes it. The application simply fails to verify that the authenticated user is authorized to perform the requested action on the requested resource. In this post, I want to walk through the patterns that show up across Python, Java, and Go, from the IDOR that any pentester would find in minutes to the subtle authorization gaps that can survive months of code review.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
