[wyc]

Pushing back on this a bit...for example, securely exposing a JSON endpoint to the public internet requires extra machinery that applications like nginx bring for free. If you simply set the router to your handler, then you accept arbitrarily large request sizes, wide open for DoS attacks. You have to either manually add limits or pull in some library. nginx caps these by default. Want throttling or load balancing? Again, things that haproxy and nginx do well, but require more cruft in your application.

[bkeroack]

I would argue that all is part of security-aware software engineering. If you aren't thinking of these things you have no business writing publicly-exposed HTTP applications.

[DandyDev]

Or... you spend your time building something useful, leveraging skills you do have, and let nginx leverage its own strengths.

What you say, sounds like NIH syndrome to me.

[bkeroack]

Secure software isn't useful? Insecure software isn't eventually value-destroying?

Really what this sub-thread is arguing is that security Isn't My Job(TM) as application developer. I disagree. Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually.

Not accepting unbound input and sane rate-limiting are kind of basic stuff, no? I'm not saying every app developer needs to be a Defcon wizard, just that they should have some fundamental awareness of secure coding standards for web apps if that's what they're building.

[stanleydrew]

> Secure software isn't useful?

Nowhere in the sub-thread is this claimed.

> Insecure software isn't eventually value-destroying?

Nowhere in this sub-thread is anyone suggesting otherwise.

> Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually.

Nobody said this. But while we're on the topic the more likely false security blanket comes from telling app devs "just use 'net/http' and 'crypto/tls' and everything will be fine without a reverse proxy."

In any case the straw men you've raised are distracting and not driving the conversation forward.

[Whitestrake]

> > Furthermore telling app devs not to worry about it because nginx takes care of everything is a false security blanket that will bite you eventually.

> Nobody said this.

That seems dishonest to say... From the grandparent:

> Or... you spend your time building something useful, leveraging skills you do have, and let nginx leverage its own strengths.

Really sounds like at least one person in this thread is advocating for app devs not to worry about things that nginx takes care of.

Agree that making straw men doesn't help. There's advice on either side regarding which one to use and realistically both are equally 'false security blankets'. The correct answer is to educate yourself on the benefit and drawbacks of each and make a conscious decision about where to implement your security.

[a-kojeve]

What if I have an application that needs to be deployed internally and externally in separate instances. Identical application, but different security contexts. Using Nginx to handle these concerns is easy.

[donalhunt]

It's a common myth that internal networks are a more secure environment. You are better off implementing the philosophy behind something like Google's BeyondCorp¹ effort.

¹ https://cloud.google.com/beyondcorp