> There’s nothing inherently insecure about exposing a service to the internet. But it does create an attack surface.
Way too many people I know work in security don’t understand this. I’ve tried explaining to people that exposing a hardened SSH endpoint is almost the same thing as exposing a VPN endpoint.
Most people think that anything public facing with authentication is by design bad. (The VPN endpoint still handles authentication btw) but fail to acknowledge the thousands and thousands of secure systems running in that fashion today that they use on a daily basis (social media, web host control panels, etc.)
Making a service publicfacing is not by itself insecure. Generally if you can avoid doing it, you should, but hardening an endpoint to make the risk satisfactory is your goal when you need to.
Public SSH is not a bad thing. Password auth, root login allowed, and no ip ban mechanism (fail2ban) is a bad security configuration.
TL;DR
Public endpoints should be hardened to what you think is an acceptable risk.
With your API, your should fuzz it and consider the attack surface inside your API.
What inputs are you accepting? Are they sanitized? Can you lock down the endpoint with authentication?
> There’s nothing inherently insecure about exposing a service to the internet. But it does create an attack surface.
Way too many people I know work in security don’t understand this. I’ve tried explaining to people that exposing a hardened SSH endpoint is almost the same thing as exposing a VPN endpoint.
Most people think that anything public facing with authentication is by design bad. (The VPN endpoint still handles authentication btw) but fail to acknowledge the thousands and thousands of secure systems running in that fashion today that they use on a daily basis (social media, web host control panels, etc.)
Making a service publicfacing is not by itself insecure. Generally if you can avoid doing it, you should, but hardening an endpoint to make the risk satisfactory is your goal when you need to.
Public SSH is not a bad thing. Password auth, root login allowed, and no ip ban mechanism (fail2ban) is a bad security configuration.
TL;DR
Public endpoints should be hardened to what you think is an acceptable risk.
With your API, your should fuzz it and consider the attack surface inside your API.
What inputs are you accepting? Are they sanitized? Can you lock down the endpoint with authentication?