Blog

How to Build an AI Security Framework for DevSecOps Teams

Flaky Tests in Software Testing: How to Identify, Fix, and Prevent Them

Test planning best practices: how TestRail simplifies test plans, milestones, and coverage

Top SonarQube Alternatives for SAST and Code Quality

<p>Most security teams already have web application and API protection, or WAAP, on the roadmap. The category makes sense. Modern applications expose APIs everywhere, and WAAP was built to defend that surface with a bundled set of capabilities that typically includes WAF, bot management, DDoS protection, and API security. What gets less attention is where that protection stops, and what remains exposed on the other side of it.</p><p>If you ship compiled or interpreted code to client devices, that gap matters more than most WAAP conversations acknowledge. WAAP protects traffic moving between clients and servers. It does not protect the code once it lands on a user-controlled endpoint and can be inspected, modified, or repackaged. That is a separate attack surface, and it needs its own controls.</p><p><strong>Key Takeaways:</strong></p><ul><li>WAAP secures the network layer through WAF, bot mitigation, DDoS protection, and API security but does not protect code once it reaches client devices<br></li><li>Adoption is growing quickly due to API expansion, cloud architectures, and compliance mandates like PCI DSS 4.0<br></li><li>Client-side code remains highly exposed and is now easier to reverse engineer as AI tools lower the technical barrier<br></li><li>Code-level protections such as obfuscation, anti-debugging, RASP, and tamper detection address this gap and extend security beyond the network boundary</li></ul><h2>What is web application and API protection (WAAP)?</h2><p>Web application and API protection (WAAP) is a security category that combines four capabilities into a single platform: web application firewall (WAF), bot management, DDoS protection, and API security. It secures the network boundary between users and your applications. Code that runs on client devices sits outside WAAP’s inspection scope.</p><p><a data-mce-href="https://www.gartner.com/reviews/market/cloud-web-application-and-api-protection" href="https://www.gartner.com/reviews/market/cloud-web-application-and-api-protection" target="_blank" rel="noopener">Gartner formalized the WAAP</a> category around four required capabilities, each addressing a distinct attack class that a traditional web application firewall couldn’t handle on its own:</p><ul><li>Web application firewall (WAF): HTTP-layer policy enforcement against injection attacks, cross-site scripting, path traversal, and the OWASP Top 10. Modern WAFs layer machine learning over signature-based rules to catch novel patterns before a new rule ships.<br></li><li>Bot management: Behavioral analysis, device fingerprinting, and challenge mechanisms that distinguish legitimate crawlers from credential-stuffing operations and scraping bots. A WAF doesn’t have the session-level visibility to do this reliably.<br></li><li>Distributed Denial of Service (DDoS) protection: Volumetric attack absorption at the edge, inline, before traffic saturates your origin.<br></li><li>API security: Discovery, schema enforcement, authentication validation, and detection of abuse patterns like broken object-level authorization and excessive data exposure.<br></li></ul><p>The API security capability is what pushed the category beyond WAF entirely. WAFs, even next-gen ones, do a poor job protecting APIs because APIs don’t follow the request patterns WAFs were built to model. That’s not a configuration problem. WAF vendors have been trying to bridge that gap for years. <strong>WAAP emerged because WAF alone was not enough to address APIs, bots, DDoS, and modern cloud traffic patterns in a single runtime protection model.</strong></p><p><a data-mce-href="https://csrc.nist.gov/pubs/sp/800/228/upd1/final" href="https://csrc.nist.gov/pubs/sp/800/228/upd1/final" target="_blank" rel="noopener">NIST SP 800-228</a>, published in June 2025 and updated in March 2026, references web application firewalls as part of API protection guidance for cloud-native systems, positioning them as components within broader API security architectures. <strong>That alignment can help security teams explain WAAP as part of a broader, standards-informed API protection architecture in procurement and audit conversations.</strong></p><h2>Why WAAP adoption is accelerating</h2><p>WAAP adoption is accelerating for structural reasons. Microservices architectures mean a single application now exposes dozens of API endpoints, each one an attack surface a perimeter firewall wasn’t designed to model. Cloud migration dissolved the network boundary those firewalls relied on.</p><p>And regulation caught up: <a data-mce-href="https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf?fv=AKHVQBp6" href="https://www.middlebury.edu/sites/default/files/2025-01/PCI-DSS-v4_0_1.pdf?fv=AKHVQBp6" target="_blank" rel="noopener">PCI DSS 4.0’s Requirement 6.4.2</a> elevates automated protection for public-facing web applications from a best-practice option to a defined requirement, mandating the use of a solution that continuously detects and prevents web-based attacks. More broadly, <a data-mce-href="https://gdpr-info.eu/art-32-gdpr/" href="https://gdpr-info.eu/art-32-gdpr/" target="_blank" rel="noopener">GDPR’s risk-based requirement</a> for appropriate technical and organizational measures supports layered security controls, even though it does not prescribe WAAP specifically.</p><p>WAAP fits how security teams actually work now. Platforms that expose management APIs can be wired into CI/CD pipelines, letting teams enforce security posture at deploy time rather than bolting it on afterward. That’s what makes WAAP a workable component of a DevSecOps workflow rather than another tool that security owns and engineering routes around. That makes WAAP easier to integrate into modern cloud security workflows instead of treating it as a standalone perimeter appliance.</p><h2>What WAAP doesn’t protect: Client-side code</h2><p>WAAP inspects traffic between clients and servers. That is its scope. Once a compiled binary, packaged mobile app, or JavaScript bundle is delivered to a client device, it falls outside WAAP’s direct field of view.</p><p>That matters because client-side code can reveal much more than teams expect. .NET assemblies and Java bytecode can often be decompiled into readable pseudo-source. Android APKs can be unpacked, modified, and repackaged. JavaScript is delivered in a form that remains structurally understandable even when it is minified. From that access, attackers can extract business logic, map API behavior, identify enforcement checks, recover sensitive strings, and modify code paths for fraud or abuse. Network-layer protection does not stop any of that once the code is already in the attacker’s hands.</p><p>How AI tools have lowered the barrier to reverse engineering<br>The code-level threat is not new. What has changed is who can carry it out and how quickly. Reverse engineering used to require deep experience with assembly, decompilers, and compiler patterns. Recent LLM-based decompilation work has lowered that barrier by helping analysts reconstruct higher-level representations from binaries and by accelerating tasks like navigation, naming, and logic recovery.</p><p>That does not mean AI can perfectly reconstruct any protected application. It does mean unprotected or lightly protected code is easier to analyze than it was a few years ago. Research in this area consistently treats readable structure and preserved patterns as helpful context for LLM-based decompilation, which is exactly why obfuscation and harder-to-interpret binaries still matter. If your security posture stops at the network layer, your client-side code is exposed to a class of tooling your WAAP deployment will never see.</p><h2>How code protection closes the WAAP gap</h2><p>Code protection secures applications at the binary level, where WAAP cannot reach. The core controls are obfuscation, control flow protection, anti-debug, runtime application self-protection (RASP), and tamper detection. Together they address the two phases attackers work in: static analysis before the code runs and dynamic analysis while it runs.</p><p>Static analysis attacks the code before it runs. Code obfuscation and control flow protection address this phase directly. Obfuscation transforms compiled code at the instruction and structural level: renaming symbols, flattening control flow, inserting opaque predicates, encrypting strings. The binary executes identically. It just stops being readable. Control flow protection restructures execution paths to defeat static analysis tools that follow the program’s logic from entry point to output, which is most of them.</p><p>Dynamic analysis attacks the code while it runs. Anti-debug controls block or detect debugger attachment, the primary tool for live inspection. Runtime application self-protection (RASP) goes further, monitoring the execution environment for signs of tampering, injection, or unauthorized instrumentation. When it detects something, it responds before the attacker gets what they came for.</p><p>Tamper detection handles the redistribution threat separately. If an attacker repackages your APK, patches your .NET assembly, or modifies your JavaScript before execution, tamper detection identifies the modification at runtime. The response depends on your policy: degrade functionality, log the event, terminate the session, or some combination. The point is that you find out, and the attacker doesn’t get a clean run.</p><h2>PreEmptive code protection tools: Dotfuscator, DashO, and JSDefender</h2><p>PreEmptive has been delivering code-level application protection for over 25 years, across the platforms where client-side exposure is actually a problem.</p><h3>Dotfuscator for .NET&nbsp;</h3><p>Dotfuscator for .NET provides code obfuscation, tamper detection, and runtime checks for .NET Framework and .NET Core applications. It integrates directly with Visual Studio and MSBuild, so protection applies at build time inside the pipelines your team already runs. It doesn’t require a separate security workflow, so protection doesn’t depend on someone remembering to run it.</p><h3>DashO for Java and Android</h3><p>DashO™ for Java and Android delivers code obfuscation, control flow protection, tamper detection, and runtime protections for Java applications and Android APKs. Android’s open distribution model means a repackaged APK with malicious modifications can appear in third-party stores within hours of your legitimate release. DashO makes that repackaging significantly harder and detectable at runtime.</p><h3>JSDefender for JavaScript</h3><p>JSDefender for JavaScript applies obfuscation and tamper detection to JavaScript running in browsers and Node.js. JavaScript is the one runtime where your code ships as near-source by definition. Minification helps with performance. It doesn’t protect your logic. JSDefender addresses the gap that most teams don’t think about until they find their algorithm running inside a competitor’s product.</p><h2>WAAP Protects The Perimeter. PreEmptive Protects The Code.</h2><p>WAAP is the right tool for securing the network boundary around your web applications and APIs. If you don’t have it deployed, that’s the first conversation to have. But for any application that ships compiled or interpreted code to client devices, the network perimeter isn’t the whole picture. The binary is a separate attack surface, and it needs its own defense.</p><p>WAAP and code protection operate on different layers. WAAP inspects traffic and blocks request-layer attacks against your servers. Code protection runs inside the application itself, defending against static analysis, reverse engineering, and runtime tampering after the binary ships. Teams that distribute client-side software need both.</p><p>PreEmptive provides that layer. With Dotfuscator, DashO, and JSDefender, you can apply code obfuscation, tamper detection, anti-debug, and runtime self-protection across your .NET, Java, Android, and JavaScript applications, integrated into the CI/CD workflows you’re already running. Start your free trial today.</p><h2>&nbsp;FAQ</h2><p><strong>What is the difference between WAAP and WAF?</strong><br>A WAF is one part of WAAP. WAAP expands beyond WAF by bundling additional controls such as bot management, DDoS protection, and API security into a broader runtime protection category.</p><p><br><strong>Does WAAP protect client-side code?</strong><br>No. WAAP protects traffic and runtime interaction at the network and API layer. It does not protect code once that code is delivered to a client device and can be inspected or modified locally.</p><p><br><strong>Why is client-side code still a security problem if the API is protected?</strong><br>Because attackers do not always need to attack the network path directly. They can inspect the application itself to understand business logic, identify enforcement points, recover sensitive strings, or modify code paths to change behavior. That exposure exists even if the API perimeter is well defended.</p><p><br><strong>How does AI affect reverse engineering risk?</strong><br>AI-assisted decompilation and binary analysis tools make reverse engineering more accessible and faster than it used to be, especially for unprotected or lightly protected applications. They do not eliminate the value of protection, but they do make code-level defenses more urgent.</p><p><br><strong>How does PreEmptive fit into a WAAP strategy?</strong><br>PreEmptive does not replace WAAP. It complements it by protecting the client-side application layer. Dotfuscator, DashO, and JSDefender are positioned to help teams defend .NET, MAUI, Java, Android, and JavaScript applications against reverse engineering, tampering, debugging, and related runtime abuse.<br>Try PreEmptive&nbsp;</p><p><a data-mce-href="https://account.preemptive.com/registration/?getevalbutton=1/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" href="https://account.preemptive.com/registration/?getevalbutton=1/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" target="_blank" rel="noopener">Try PreEmptive Today</a></p>

Web Application and API Protection (WAAP) Guide

<p>In recent years, Android app development has undergone significant changes. Applications are now larger, more modular, and distributed through Google’s App bundle format rather than a flat APK. As the Java platform evolves as well, it’s essential for developers’s tools to keep pace with these advancements—and DashO is focused on expanding protection coverage to match how Android and Java applications are built and shipped today.</p><h3>Stronger production-scale Android coverage&nbsp;</h3><p>When an Android app grows beyond a certain size by pulling in third-party libraries, it eventually exceeds Android’s 65k method limit. Once this happens, Android solves the problem &nbsp;with multidex APK—which splits the code across multiple DEX files. The app loads these during runtime, and everything works efficiently. But this comes with challenges: and in order for an obfuscation security tool to handle multidex correctly, it needs to be able to process and reassemble multiple DEX files as a bundle, not process these files one at a time. DashO 12.8.0 now does this seamlessly.</p><p>With this release, developers can:</p><ul><li>Secure their process through obfuscation, and repackage files into correct, distributable outputs on multidex APKs. &nbsp;<br></li><li>Remove friction in the pipeline for development teams working on production-scale Android applications.&nbsp;<br></li></ul><h3>Application protection before it reaches the Play Store<br></h3><p>Android App Bundle (AAB) is Google’s preferred app distribution for the Play Store. For many years the recommended approach has been for developers to let Google generate device-optimized APKs for every user, rather than uploading individual universal APKs. And with security at the forefront, developers who wanted to apply protection to their AAB faced &nbsp;extensive additional work––until now.&nbsp;</p><p>Developers can now:</p><ul><li>Input all finished AABs directly into DashO—which can unpack the bundle, obfuscate all contained code, and repackage it fully protected for Play Store, with no additional workarounds.&nbsp;<br></li></ul><h3>Continued Java 26 Support&nbsp;</h3><p>Java 26 is the latest version that continues to evolve at a steady pace. This release ensures DashO effectively manages applications targeting Java 26 without errors or output regressions. It also covers typical situations where a development team upgrades their target Java Development Kit (JDK) prior to implementing any new language features.&nbsp;</p><p>With this release, developers can:</p><ul><li>Confidently obfuscate their applications, whether they’ve only updated the targeted JDK or new Java 26 features.<br>Establish correct classfile version handling.&nbsp;<br></li><li>Support for Java 25, 21, and all earlier LTS versions continues unchanged.</li></ul><h3>PreEmptive safeguards your applications</h3><p>DashO 12.8.0 fully supports Android multidex APKs and AAB along with stronger continued coverage for Java 26, and is now available for all PreEmptive customers with active licences.&nbsp;</p><p>New to DashO? <a data-mce-href="https://account.preemptive.com/registration/?getevalbutton=1/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" href="https://account.preemptive.com/registration/?getevalbutton=1/?utm_source=partners_website&amp;utm_medium=partners&amp;utm_campaign=dube&amp;utm_term=&amp;utm_content=free_trial" target="_blank" rel="noopener">Start a free trial</a> to see how easy it is to add enterprise-grade protection to your Android and Java applications.</p>

DashO introduces wider Android and Java coverage

Dube Insights

Distributor of quality & test management, automated testing and security solutions.

Poppins

IBM Plex Mono

IBM Plex Sans

Roboto

<p>By continuing to use this website, you consent to the use of cookies in accordance with our Privacy Policy.</p>
<p>Please click the privacy policy button at the bottom of the page to view our privacy policy.</p>

Blog

How to Build an AI Security Framework for DevSecOps Teams

Flaky Tests in Software Testing: How to Identify, Fix, an...

Test planning best practices: how TestRail simplifies tes...

Top SonarQube Alternatives for SAST and Code Quality

Web Application and API Protection (WAAP) Guide

DashO introduces wider Android and Java coverage