[johnbillow]

Seems like you didn't really go through the document mate. What you are saying is exactly the opposite of what I saw. Each section actually has a "difference" between traditional and serverless apps. Moreover, if you read the beginning, they point out the reasons why WAFs are irrelevant...

[mi100hael]

Seems like you didn't really understand my comment mate. My point is that this link is blowing smoke and there are no substantial differences at the application layer.

There's no difference in security considerations when interacting with external resources at the application level. Either way you better have some form of auth and be sending credentials over TLS.

WAFs aren't irrelevant since from an external perspective there's no discernible difference between a request like

    POST /login?user=root&password=' OR 1=1 --

being made to a handler running full-time on a dedicated web server or on-demand on AWS Lambda behind API Gateway.

[johnbillow]

So you yourself are only discussing HTTP. What about other types of serverless event triggers? do you know how to protect against injections in SNS? or what happens when you inject malicious input into data coming from S3? So yes, app security is app security, but there are nuances and pitfalls that are serverless specific...

[mi100hael]

You do realize that plenty of applications were handling events and files "serverless" was even a thing, right? Even in a cloud context, SNS and S3 long pre-date Lambda. Neither of those "pitfalls" are serverless specific.

In fact, Lambdas (and every other serverless platform I'm aware of) execute with the same isolation as EC2 instances in AWS. There are effectively no differences security-wise between code executing on an EC2 and code executing in Lambda. Any vulnerability in a Lambda function is also going to be a vulnerability in a traditional application hosted on EC2 and vice versa.