<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Error Handling on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/error-handling/</link>
    <description>Recent content in Error Handling on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 27 Sep 2025 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/error-handling/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Go Security: Goroutines, Error Handling, and Hidden Bugs</title>
      <link>https://www.secdev.uk/blog/technology/2025-09-27-go-security-goroutines-errors/</link>
      <pubDate>Sat, 27 Sep 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-09-27-go-security-goroutines-errors/</guid>
      <description>&lt;p&gt;Go&amp;rsquo;s simplicity is its greatest strength and, I&amp;rsquo;d argue, its most dangerous security property. The language has no exceptions, no generics-based abstractions (until recently), and no implicit behaviour, everything is explicit. But that explicitness creates its own class of vulnerabilities: unchecked errors that silently skip security validation, goroutine races on shared state, HTTP client defaults that follow redirects into internal networks, and string handling patterns that bypass input validation. In this post, I want to walk through the Go-specific anti-patterns that lead to security vulnerabilities, from the error that nobody checked to the goroutine that corrupted the authentication cache. The more I dug into Go&amp;rsquo;s security landscape, the more I realised these bugs are subtle precisely because the language feels so straightforward.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
