"Doesn't matter, I'll fuzz the crap out of it and find the vulnerabilities eventually"
"Input validation is still input validation, let me at it and I'll dump that database in no time."
"I'm going to pop a webshell on that server, dump credentials, and own that network."
"Okay, let's run the vulnerability scanner and see what we get back."
You get the point, this can lead to ruin. Assuming the technology based on previous training, books, and lack of development exposure when doing WAPTs can lead you down the wrong path. Reconnaissance has always been an important part of an engagement, this is even more true today. **Understand the architecture before you waste you and your clients time.** Why are you trying payloads for Angular Template Injection when the client side is written in React? How are you going to determine, or would know if state management is mishandled? Why are you checking for authentication cookies when it's using JWT? Is JWT properly implemented? If you happen to be an application developer reading this you're at least cracking a smile. The application security folks are as well, since they likely understand these deployments and the available security considerations that go into these architectures. The days of a developer not knowing how to handle authentication or authorization correctly are slowly going away with the shift in reliance on cloud providers and third-party services. Why roll my own auth when I can use Cognito? What I'm saying is the default security posture of applications is getting more mature as the application development and application security ecosystem continue to progress. More mature, but still not secure. As mentioned before, the gap is in the offensive security tools and the assumptions we make when approaching WAPTS. Using common security tools on an engagement tends to lead to false positives and traditional coverage of HTTP interfaces, but can't handle REST APIs without contextual awareness. Client-side state management and front-end logic handling throws tools for a loop. Handling GraphQL endpoints in an automated fashion is almost out of the question. On to manual testing, since we are doing a pentest right? The offensive approach to cloud-native deployments is different than for traditional monolithic on-prem deployments, and puts a heavier focus on client site input validation, API testing, authentication, authorization, and business logic. There are no CSRF attacks when using JWT. Directory traversal is out of the question due to dynamic routing in SPA. You can't SQLi to dump credentials when using an Cognito endpoint. It doesn't matter if you RCE an underlying S3 bucket, instead you want code execution on the application server run-time environment. When approaching Lambda functions, S3, and container instances, at the OS level there has to be an understanding of what is AWS territory and what is client territory. See the shared responsibility model. Of course, these are some forced examples to make a point that the landscape has shifted. Ultimately the point I'm trying to make is: **The more you understand about development and deployment capabilities, and overall application security within the SDLC, the more effective the penetration test will be.** It's an obvious statement I'm sure, but you can't be a truly effective offensive player if don't keep up with the defensive and production capabilities. Now, it is important to understand that cloud-native architectures are not bulletproof, it's just a shift in the attack surface. Increased complexity brings a new array of issues, like mishandling of JWT tokens (https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/), improper input validation, leaking of secrets and access tokens in source control, and over-permissive authorization. This names a few, but the list goes on. Keep an eye on HackerOne's Hactivity (https://hackerone.com/hacktivity) for some examples. Remember, combine the human element with the increased need for speed and scalability and mistakes will always happen. To effectively test an environment, consider your threat model and emulate those threats in your penetration tests along with a testing approach that stems from your understanding of the ecosystem. Additionally, consider doing a secure architecture review with the client to provide input on secure best practices and highlight potential issues that reside behind the scenes. We've found a combination of these to be effective in ensuring coverage. Again, the more you understand about the applications architecture and it's business objectives the more effective your security work will be. Take the time to keep up with full stack development capabilities, cloud-native architectures and the application security strategies that go with it. It's not always about security testing, and it's easy to get left behind if you aren't careful At OccamSec, we are always striving to stay up to date on both development and app sec practices to steer our continued security research, and ensure our WAPT methodology is effective when testing the most bleeding-edge deployments.