Go on guy@secdev.uk

Deserialization Attacks: From Pickle to ObjectInputStream

Sat, 28 Feb 2026 00:00:00 +0000

Deserialization vulnerabilities are some of the scariest bugs in application security, because when they’re exploitable, it’s almost always remote code execution. The core problem is that an application reconstructs objects from untrusted data without validating what types are being instantiated. In languages with powerful serialization mechanisms – Python’s pickle, Java’s ObjectInputStream, PHP’s unserialize – an attacker can craft serialized payloads that execute arbitrary code during the deserialization process itself. The more I researched how these attacks work across languages, the more I appreciated how a single API call can turn into a full server compromise.

CORS Misconfiguration: The Open Door You Didn't Know About

Sat, 14 Feb 2026 00:00:00 +0000

CORS misconfiguration is one of those vulnerabilities that keeps coming up because most developers don’t fully understand what CORS actually does. It’s the browser mechanism that controls which websites can make requests to your API. When it’s configured correctly, it prevents malicious sites from stealing data through a victim’s browser. When it’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’re invisible to users, silent in server logs, and trivial to exploit.

XXE Attacks: XML Parsing Gone Wrong

Sat, 31 Jan 2026 00:00:00 +0000

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.

Secrets in Source Code: Finding and Eliminating Hardcoded Credentials

Sat, 17 Jan 2026 00:00:00 +0000

Hardcoded credentials are one of the most common and most preventable vulnerability classes out there. API keys, database passwords, encryption keys, and service tokens embedded directly in source code end up in version control, build artifacts, container images, and log files. Once a secret reaches a Git repository, it persists in the history even after the offending line is deleted. When I started researching how often this happens in practice, the numbers were staggering, public reports of leaked credentials on GitHub alone run into the millions per year. In this post I’ll cover the patterns that lead to hardcoded secrets, the tools that detect them, and the architecture changes that eliminate them for good.

Go Learning Guide

Tue, 06 Jan 2026 00:00:00 +0000

A structured learning guide for developers coming from Java, C, or Python who want to learn Go. I put this together because when I started learning Go myself, I kept wishing for a resource that mapped Go’s idioms back to languages I already knew. Github Repo of Code Examples

Introduction to Go

Go (also called Golang) was created at Google in 2009 by Robert Griesemer, Rob Pike, and Ken Thompson. It was designed to address the challenges of building large-scale, concurrent software systems while keeping the language simple and productive.

String Formatting and Security: A Cross-Language Minefield

Sat, 03 Jan 2026 00:00:00 +0000

String formatting is one of those operations that’s everywhere, and it’s more dangerous than most developers realise when user input gets involved. Every language provides multiple ways to build strings from dynamic data, and each mechanism carries different security implications. From C’s printf family, where a format string bug can read and write arbitrary memory, to Python’s f-strings that can execute attribute lookups, the attack surface is broader than most people think. I wanted to map out the full landscape across languages, and what I found was that each mechanism breaks down in its own unique and sometimes surprising way.

SAST Tools Compared: What They Catch and What They Miss

Sat, 20 Dec 2025 00:00:00 +0000

Static Application Security Testing (SAST) tools are the first line of automated defence against vulnerabilities in source code. They analyse code without executing it, looking for patterns that match known vulnerability classes. But here’s the thing, no single tool catches everything, and the differences between tools in detection capability, false positive rates, and language support are significant. I wanted to understand exactly where the gaps are, so I spent time running these tools against intentionally vulnerable code and comparing their output. This post is my honest assessment of what they actually catch, what they miss, and where manual review has to pick up the slack.

The Art of the Subtle Bug: Nuanced Vulnerabilities That Evade Review

Sat, 06 Dec 2025 00:00:00 +0000

The vulnerabilities that cause real breaches are rarely the textbook examples. They’re the ones that survive multiple rounds of code review, pass SAST scans, and sit in production for years. The more I researched these nuanced bugs, the more I realised what makes them dangerous: they exploit assumptions reviewers make about language behaviour, framework internals, or data flow boundaries. This post dissects the patterns that make a vulnerability subtle and walks through real examples that show why even experienced reviewers still miss them.

Go Security: Goroutines, Error Handling, and Hidden Bugs

Sat, 27 Sep 2025 00:00:00 +0000

Go’s simplicity is its greatest strength and, I’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’s security landscape, the more I realised these bugs are subtle precisely because the language feels so straightforward.

Race Conditions

Sat, 16 Aug 2025 00:00:00 +0000

Race conditions (CWE-362) are, in my opinion, the most insidious class of security bugs you’ll encounter. They occur when the behaviour of a program depends on the relative timing of concurrent operations, and at least one of those operations modifies shared state. The window between a check and a subsequent use of the checked value, the classic time-of-check to time-of-use (TOCTOU) pattern, is the most exploited form, but races also show up in counter increments, balance updates, session management, and file operations. What makes race conditions uniquely dangerous is their non-determinism: the bug may not manifest in thousands of test runs, then appear under production load when two requests arrive within microseconds of each other. I want to walk through race conditions in Python, Go, Java, and Rust, from the obvious unprotected counter to the subtle channel-based ordering assumption that passes every test but fails under contention.

Integer Overflow

Sat, 02 Aug 2025 00:00:00 +0000

Integer overflow (CWE-190) is one of those bugs that I find endlessly fascinating because of how quietly destructive it is. It happens when an arithmetic operation produces a value that exceeds the maximum (or falls below the minimum) representable value for the integer type. In C and C++, signed integer overflow is undefined behaviour, the compiler is free to assume it never happens, and optimizations built on that assumption can eliminate bounds checks entirely. Unsigned overflow wraps around silently. Go and Java define overflow as wrapping (two’s complement), which prevents undefined behaviour but still produces incorrect results that lead to security vulnerabilities: undersized allocations, bypassed length checks, and negative indices into arrays. Rust panics on overflow in debug mode but wraps in release mode by default, creating a gap between testing and production behaviour that caught me off guard when I first started digging into Rust’s safety guarantees. I want to walk through integer overflow across C, C++, Rust, Go, and Java, from the textbook multiplication overflow to the subtle cast truncation that can survive expert review.

Null Pointer Dereference

Sat, 19 Jul 2025 00:00:00 +0000

Null pointer dereference (CWE-476) is one of those bugs that shows up across every language, and the more I researched it for this post, the more I was struck by how much damage it can do depending on context. The consequences vary dramatically: C programs crash with a segfault (or worse, the kernel maps page zero and an attacker gets code execution), C++ invokes undefined behaviour that the compiler may optimise into literally anything, Go panics with a nil pointer dereference that kills the goroutine or the whole program, and Java throws a NullPointerException that can crash the app or leak stack traces to an attacker. MITRE ranks CWE-476 consistently in the top 25 most dangerous software weaknesses, and digging into the CVE data, that ranking is well deserved. I want to walk through C, C++, Go, and Java here, from the obvious unchecked malloc return to the subtle nil interface trap in Go and the conditional path where null silently propagates through multiple function calls.

SSRF

Sat, 07 Jun 2025 00:00:00 +0000

Server-Side Request Forgery is one of those vulnerability classes that I’ve grown to respect more and more the deeper I dig into it. The idea is simple, you trick a server into making HTTP requests to destinations you choose, turning it into your personal proxy. It can reach internal services, cloud metadata endpoints, and private networks that you’d never touch directly from the outside. OWASP gave SSRF its own category (A10) in 2021, and reading through the rationale, it was overdue. The case studies are striking, a single SSRF against http://169.254.169.254/ on AWS can leak IAM credentials and compromise an entire account. In this post, I’ll walk through Python, Java, Go, and JavaScript examples, from the textbook URL-in-a-parameter to the subtle redirect-chain and DNS rebinding variants that make SSRF so hard to defend against.

Logging Failures

Sat, 24 May 2025 00:00:00 +0000

When I started researching logging failures for this post, I expected to find dramatic exploit chains. Instead, what I found was something more unsettling, the absence of evidence. The most frustrating thing about incident response isn’t finding a sophisticated exploit; it’s opening the log aggregator and finding nothing. No entries, no breadcrumbs, no evidence that anything happened at all. That’s CWE-778 (Insufficient Logging), and it’s the backbone of OWASP A09: Security Logging and Monitoring Failures. This isn’t a crash or a data leak in the traditional sense; it’s the absence of evidence. When your incident response team can’t investigate what was never recorded, the attacker wins by default. In this post, I’m going to walk through logging failures across Python, Java, and Go, from the obvious missing-log-statement to the subtle cases where logging exists but captures the wrong data, at the wrong level, or silently drops events under load.

Integrity Failures

Sat, 10 May 2025 00:00:00 +0000

Integrity failures happen when an application trusts data or code that hasn’t been verified, and they can lead to some of the most devastating compromises out there. OWASP A08 covers two patterns I find particularly fascinating: unsafe deserialization (CWE-502), where untrusted data is fed into a deserializer that can execute arbitrary code, and inclusion of functionality from untrusted sources (CWE-829), where the application loads and runs code from URLs, plugins, or scripts without integrity checks. Both patterns share a root cause, the application assumes that incoming data or code is benign. In this post I’ll walk through Python, Java, JavaScript, and Go, from the textbook pickle.loads() to the subtle VM sandbox escapes that can survive expert review.

Authentication Failures

Sat, 26 Apr 2025 00:00:00 +0000

Authentication is the front door of every application, and OWASP A07 documents how often that door is left unlocked. When I started digging into authentication failures, I realised they go far beyond weak passwords, they encompass hardcoded credentials compiled into binaries, brute-force attacks with no rate limiting, password hashes that can be reversed in seconds, and reset flows that hand tokens directly to attackers. These patterns show up in production regularly, sometimes in the same application. This post covers three CWEs across Python, Java, Go, and Rust: CWE-798 (Use of Hard-Coded Credentials), CWE-287 (Improper Authentication), and CWE-307 (Improper Restriction of Excessive Authentication Attempts).

Security Misconfiguration

Sat, 29 Mar 2025 00:00:00 +0000

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 can 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’t coding mistakes, they’re configuration mistakes, and they show up everywhere. In this post I’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.

Cryptographic Failures That Pass Code Review

Sat, 01 Mar 2025 00:00:00 +0000

Cryptographic code is uniquely dangerous, and it’s one of the areas I find most challenging to review. The reason is simple: it can be completely wrong and still appear to work perfectly. A broken hash function still produces a hash. A weak cipher still encrypts and decrypts. A predictable random number generator still generates numbers. The application runs, tests pass, and the vulnerability sits quietly until an attacker exploits it. In this post, I want to walk through the cryptographic failures that routinely survive code review across Python, Java, Go, and Rust, from the obvious use of MD5 to the subtle misuse of otherwise strong primitives.

Broken Access Control

Sat, 15 Feb 2025 00:00:00 +0000

Broken access control sits at the top of the OWASP Top 10 for good reason, and it’s the vulnerability class I find most fascinating to research. It’s the most common serious vulnerability in modern web applications, and it’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.

XSS Is Not Just a JavaScript Problem

Sat, 01 Feb 2025 00:00:00 +0000

Cross-site scripting gets framed as a front-end problem a lot, something that happens in JavaScript and gets fixed with JavaScript. But the more I dug into this, the clearer it became that XSS vulnerabilities almost always originate on the server side, in whatever language is generating the HTML. I’ve found XSS in Python templates, Java JSPs, Go’s html/template misuse, Rust web frameworks, and server-rendered JavaScript. The language you write your backend in determines which XSS patterns you’ll run into and which ones will sneak past your review.

Command Injection Beyond os.system

Sat, 18 Jan 2025 00:00:00 +0000

When most developers hear “command injection,” they think of os.system() in Python or Runtime.exec() in Java. Those are the textbook examples, and most teams know to avoid them. But the more I researched this topic, the more I realised that command injection surfaces through dozens of less obvious APIs across every language, subprocess pipes, shell expansions, backtick operators, and even seemingly safe exec functions that become dangerous with the wrong arguments. This is one of my favourite vulnerability classes to dig into because the attack surface is so much wider than people realise. Let me walk you through command injection patterns across seven languages, from the obvious to the genuinely subtle.

SQL Injection Across Languages

Sat, 04 Jan 2025 00:00:00 +0000

SQL injection is one of those vulnerability classes that refuses to go away, no matter how much the industry talks about it. I’ve been digging into how it manifests across different languages, Python, Java, Go, and JavaScript, and the root cause is always the same: untrusted input reaches a SQL query without proper parameterization. But the way developers introduce it varies wildly depending on the framework, ORM, and idioms of each language. In this post, I want to walk through real examples across these four languages, showing both the obvious patterns that any reviewer would catch and the subtle ones that slip through code review more often than you’d expect.