<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>JavaScript on guy@secdev.uk</title>
    <link>https://www.secdev.uk/blog/tags/javascript/</link>
    <description>Recent content in JavaScript on guy@secdev.uk</description>
    <generator>Hugo</generator>
    <language>en-gb</language>
    <copyright>Guy Dixon | guy@secdev.uk</copyright>
    <lastBuildDate>Sat, 28 Feb 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://www.secdev.uk/blog/tags/javascript/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Deserialization Attacks: From Pickle to ObjectInputStream</title>
      <link>https://www.secdev.uk/blog/technology/2026-02-28-deserialization-attacks/</link>
      <pubDate>Sat, 28 Feb 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-02-28-deserialization-attacks/</guid>
      <description>&lt;p&gt;Deserialization vulnerabilities are some of the scariest bugs in application security, because when they&amp;rsquo;re exploitable, it&amp;rsquo;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 &amp;ndash; Python&amp;rsquo;s &lt;code&gt;pickle&lt;/code&gt;, Java&amp;rsquo;s &lt;code&gt;ObjectInputStream&lt;/code&gt;, PHP&amp;rsquo;s &lt;code&gt;unserialize&lt;/code&gt; &amp;ndash; 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.&lt;/p&gt;</description>
    </item>
    <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>Secrets in Source Code: Finding and Eliminating Hardcoded Credentials</title>
      <link>https://www.secdev.uk/blog/technology/2026-01-17-secrets-in-source-code/</link>
      <pubDate>Sat, 17 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-01-17-secrets-in-source-code/</guid>
      <description>&lt;p&gt;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&amp;rsquo;ll cover the patterns that lead to hardcoded secrets, the tools that detect them, and the architecture changes that eliminate them for good.&lt;/p&gt;</description>
    </item>
    <item>
      <title>String Formatting and Security: A Cross-Language Minefield</title>
      <link>https://www.secdev.uk/blog/technology/2026-01-03-string-formatting-and-security/</link>
      <pubDate>Sat, 03 Jan 2026 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2026-01-03-string-formatting-and-security/</guid>
      <description>&lt;p&gt;String formatting is one of those operations that&amp;rsquo;s everywhere, and it&amp;rsquo;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&amp;rsquo;s &lt;code&gt;printf&lt;/code&gt; family, where a format string bug can read and write arbitrary memory, to Python&amp;rsquo;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>JavaScript Security: Prototype Pollution to Supply Chain Attacks</title>
      <link>https://www.secdev.uk/blog/technology/2025-11-22-javascript-security-prototype-pollution/</link>
      <pubDate>Sat, 22 Nov 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-11-22-javascript-security-prototype-pollution/</guid>
      <description>&lt;p&gt;JavaScript is the one language I can never escape, it&amp;rsquo;s on both sides of the web. In the browser it handles user interaction and DOM manipulation, and on the server Node.js powers APIs, microservices, and build tools. This dual nature creates an attack surface that&amp;rsquo;s uniquely challenging to secure. Browser-side JavaScript faces XSS, DOM clobbering, and postMessage abuse. Server-side JavaScript faces prototype pollution, dependency confusion, ReDoS, and the vast npm ecosystem where a single malicious package can compromise thousands of applications. In this post, I want to walk through the JavaScript-specific anti-patterns that keep coming up, from the prototype chain manipulation that poisons every object in the runtime to the regex that freezes your server.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SSRF</title>
      <link>https://www.secdev.uk/blog/technology/2025-06-07-ssrf/</link>
      <pubDate>Sat, 07 Jun 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-06-07-ssrf/</guid>
      <description>&lt;p&gt;Server-Side Request Forgery is one of those vulnerability classes that I&amp;rsquo;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&amp;rsquo;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 &lt;code&gt;http://169.254.169.254/&lt;/code&gt; on AWS can leak IAM credentials and compromise an entire account. In this post, I&amp;rsquo;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Integrity Failures</title>
      <link>https://www.secdev.uk/blog/technology/2025-05-10-integrity-failures/</link>
      <pubDate>Sat, 10 May 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-05-10-integrity-failures/</guid>
      <description>&lt;p&gt;Integrity failures happen when an application trusts data or code that hasn&amp;rsquo;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&amp;rsquo;ll walk through Python, Java, JavaScript, and Go, from the textbook &lt;code&gt;pickle.loads()&lt;/code&gt; to the subtle VM sandbox escapes that can survive expert review.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Vulnerable Components</title>
      <link>https://www.secdev.uk/blog/technology/2025-04-12-vulnerable-components/</link>
      <pubDate>Sat, 12 Apr 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-04-12-vulnerable-components/</guid>
      <description>&lt;p&gt;Your application is only as secure as its least-maintained dependency, and this is one of those lessons that really sinks in once you start digging into dependency trees. OWASP A06 (Vulnerable and Outdated Components) covers the reality that most modern applications are more dependency code than application code, and a single outdated library can undermine every security measure you&amp;rsquo;ve built. CWE-1104 captures this: the use of unmaintained third-party components with known vulnerabilities. In this post I&amp;rsquo;ll walk through real dependency chains in Python, Java, and JavaScript, from the Log4Shell-level disasters that make headlines to the subtle version pins that quietly accumulate CVEs while nobody&amp;rsquo;s watching.&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>
    <item>
      <title>Insecure Design</title>
      <link>https://www.secdev.uk/blog/technology/2025-03-15-insecure-design/</link>
      <pubDate>Sat, 15 Mar 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-03-15-insecure-design/</guid>
      <description>&lt;p&gt;Insecure design is the vulnerability class that fascinates me the most, because no amount of perfect implementation can fix it. It lives in the architecture, the data flow, the decisions made before anyone wrote a line of code. OWASP A04 captures something that shows up again and again in real-world applications: systems that are insecure by design, not because of a coding mistake, but because the system was never designed to be secure in the first place. In this post, I want to focus on two of the most common manifestations: verbose error messages that leak internal details (CWE-209) and insufficiently protected credentials (CWE-522). I&amp;rsquo;ll walk through Python, Java, and JavaScript examples that range from the immediately obvious to the patterns that, from what I&amp;rsquo;ve seen in code reviews, can survive months without being caught.&lt;/p&gt;</description>
    </item>
    <item>
      <title>XSS Is Not Just a JavaScript Problem</title>
      <link>https://www.secdev.uk/blog/technology/2025-02-01-xss-is-not-just-a-javascript-problem/</link>
      <pubDate>Sat, 01 Feb 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-02-01-xss-is-not-just-a-javascript-problem/</guid>
      <description>&lt;p&gt;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&amp;rsquo;ve found XSS in Python templates, Java JSPs, Go&amp;rsquo;s &lt;code&gt;html/template&lt;/code&gt; misuse, Rust web frameworks, and server-rendered JavaScript. The language you write your backend in determines which XSS patterns you&amp;rsquo;ll run into and which ones will sneak past your review.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Command Injection Beyond os.system</title>
      <link>https://www.secdev.uk/blog/technology/2025-01-18-command-injection-beyond-os-system/</link>
      <pubDate>Sat, 18 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-01-18-command-injection-beyond-os-system/</guid>
      <description>&lt;p&gt;When most developers hear &amp;ldquo;command injection,&amp;rdquo; they think of &lt;code&gt;os.system()&lt;/code&gt; in Python or &lt;code&gt;Runtime.exec()&lt;/code&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>SQL Injection Across Languages</title>
      <link>https://www.secdev.uk/blog/technology/2025-01-04-sql-injection-across-languages/</link>
      <pubDate>Sat, 04 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/technology/2025-01-04-sql-injection-across-languages/</guid>
      <description>&lt;p&gt;SQL injection is one of those vulnerability classes that refuses to go away, no matter how much the industry talks about it. I&amp;rsquo;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&amp;rsquo;d expect.&lt;/p&gt;</description>
    </item>
    <item>
      <title>JavaScript Security Code Review Guide</title>
      <link>https://www.secdev.uk/blog/articles/javascript_security_review_guide/</link>
      <pubDate>Wed, 09 Oct 2024 00:00:00 +0000</pubDate>
      <guid>https://www.secdev.uk/blog/articles/javascript_security_review_guide/</guid>
      <description>&lt;h2 id=&#34;1-introduction&#34;&gt;1. Introduction&lt;/h2&gt;&#xA;&lt;p&gt;I put this guide together as a structured approach to security-focused code review for JavaScript and Node.js applications. Whether you&amp;rsquo;re just starting to identify security vulnerabilities in JavaScript code or you&amp;rsquo;re an experienced developer looking for a language-specific checklist, I&amp;rsquo;ve tried to make it useful at both levels.&lt;/p&gt;&#xA;&lt;p&gt;JavaScript&amp;rsquo;s dynamic typing, prototype-based inheritance, single-threaded event loop with async concurrency, and the vast npm ecosystem make it enormously productive, but the more I dug into JavaScript security, the more I realised these same qualities introduce security pitfalls that static analysis alone cannot always catch. What follows covers manual review strategies, common anti-patterns, recommended tooling, and vulnerability patterns organised by class, with cross-references to the intentionally vulnerable examples in this project.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
