<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Information Disclosure on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/information-disclosure/</link>
    <description>Recent content in Information Disclosure on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 25 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/information-disclosure/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Error Handling as a Security Feature</title>
      <link>https://www.secdev.uk/blog/technology/2026-04-25-error-handling-as-security-feature/</link>
      <pubDate>Sat, 25 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-04-25-error-handling-as-security-feature/</guid>
      <description>&lt;p&gt;After our detour into the past with our vintage computer deep dives, here we are looking into common security concerns.&lt;/p&gt;&#xA;&lt;p&gt;Most developers think of error handling as a reliability concern, catch exceptions, log them, show the user a friendly message. But the more I&#39;ve studied real-world vulnerabilities, the more I&#39;ve come to see error handling as one of the most critical security boundaries in any application. Verbose error messages leak implementation details to attackers. Uncaught exceptions bypass security checks. Inconsistent error responses enable user enumeration. And swallowed errors hide security-relevant failures that should be setting off alarms. In this post, I want to cover the security implications of error handling patterns that keep showing up across languages, and how to build error handling that actually strengthens your security posture instead of undermining it.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
