Insecure Deserialization
A vulnerability arising when an application deserialises attacker-controlled data into objects without validation, allowing manipulation of application logic, privilege escalation or, with a suitable gadget chain, remote code execution. It is most dangerous in formats that can encode arbitrary object types and invoke methods during reconstruction, such as Java serialization, Python pickle, PHP unserialize and .NET BinaryFormatter. Examined in GWAPT, OSWE, CSSLP and secure-development domains.
Why It Matters
In practice the crucial insight is that the vulnerability is in the act of deserialising untrusted input at all, not in a filter that missed something -- the format's ability to reconstruct arbitrary objects and trigger code during that reconstruction is the attack surface, so signature-based blocklists of known gadget classes are a stopgap that new gadget chains routinely defeat. The sound answer is to avoid native deserialization of untrusted data entirely, using a data-only format such as JSON parsed into known types, and where a native format is unavoidable, to integrity-protect the payload with an HMAC so foreign objects never reach the deserialiser. It is also the reason Python's pickle is unsafe for model files and cached artefacts -- a relevant, current concern for machine-learning supply chains, where a downloaded model can execute code on load. Look for serialized blobs in cookies, hidden fields, caches and message queues. On exams, expect questions on why validation after deserialization is too late.
Practice this topic
Test your knowledge of Insecure Deserialization concepts with exam-style practice questions.
Related Application Security terms
OWASP
The Open Web Application Security Project, a nonprofit foundation focused on improving software security through community-led open-source projects, tools, documentation, and standards. OWASP is best known for the OWASP Top 10, a regularly updated list of the most critical web application security risks (including injection, broken authentication, XSS, and security misconfiguration). Other key projects include the OWASP Testing Guide, ASVS (Application Security Verification Standard), ZAP (Zed Attack Proxy), and the Mobile Security Testing Guide. OWASP resources are referenced across virtually every security certification and are the de facto standard for web application security assessments.
SAST (Static Application Security Testing)
A testing methodology that analyzes source code, bytecode, or binary code for security vulnerabilities without executing the program, often called 'white-box' testing. SAST tools scan codebases for patterns that match known vulnerability types such as SQL injection, XSS, buffer overflows, and hardcoded credentials. They integrate into CI/CD pipelines to catch issues early in the development lifecycle (shift-left security). Popular SAST tools include SonarQube, Checkmarx, Semgrep, and Fortify. SAST complements DAST (runtime testing) and is a fundamental practice in DevSecOps and secure SDLC, tested in CSSLP and DevSecOps certifications.
DAST (Dynamic Application Security Testing)
A testing methodology that analyzes running applications for vulnerabilities by simulating external attacks without access to source code, often called 'black-box' testing. DAST tools interact with the application through its interfaces (HTTP requests, APIs) to find issues like injection flaws, authentication problems, configuration errors, and sensitive data exposure. Unlike SAST, DAST finds runtime-specific issues but cannot pinpoint the exact line of vulnerable code. Popular DAST tools include OWASP ZAP, Burp Suite, Nikto, and Acunetix. DAST is used alongside SAST in a comprehensive application security program and is tested in CEH, OSCP, and DevSecOps certifications.
DevSecOps
An approach that integrates security practices within the DevOps process throughout the entire software development lifecycle, making security a shared responsibility rather than an afterthought. DevSecOps automates security testing at every stage: SAST in code commits, dependency scanning in builds, DAST in staging, infrastructure-as-code scanning, and container image scanning before deployment. Key principles include shift-left security, security as code, automated compliance checks, and continuous monitoring in production. Tools include GitHub Advanced Security, Snyk, HashiCorp Vault, and Falco. DevSecOps is increasingly tested in CISSP, CSSLP, and dedicated DevSecOps foundation certifications.
CSRF (Cross-Site Request Forgery)
An attack that forces authenticated users to submit unwanted requests to a web application where they are currently logged in, exploiting the trust that the site has in the user's browser. For example, an attacker could craft a link that transfers funds or changes account settings when clicked by a logged-in user. CSRF works because browsers automatically include session cookies with every request to a domain. Defenses include anti-CSRF tokens (synchronizer tokens), SameSite cookie attributes, checking the Origin/Referer headers, and requiring re-authentication for sensitive actions. CSRF is an OWASP Top 10 vulnerability and is tested in CEH, OSCP, and web application security certifications.
Mobile Application Security
The practice of securing mobile apps and the data they hold, spanning insecure local storage, weak transport protection, hardcoded secrets in the package, misused platform APIs, and inadequate resistance to reverse engineering or tampering on a device the owner fully controls. The OWASP Mobile Application Security Verification Standard (MASVS) and its testing guide define the accepted requirement levels, and OWASP MASVS is a certification track in its own right. Mobile app security appears in CMPen-Android, eMAPT, OWASP MASVS and CSSLP domains.