Transport-level security is service-independent

As a service developer, you usually don’t need to be concerned with how the service has been secured.

Administrators attach security definitions to channels to make sure only permitted applications have access to a service and when you’re authoring a service which you know will be using one of the three methods of securing the transport layer, you can simply assume that the authentication has been performed elsewhere by Zato itself, you don’t need to add any code yourself.

Naturally, if you’d like to use any other authentication scheme, one which Zato doesn’t support out of the box, your service is free to manually check access permissions, Zato won’t interfere with it in any way.

General recommendations

From a security-conscious programmer’s point of view, Zato is essentially a server that accepts input from potentially hostile sources and transforms it into an output of some sort.

As such, despite its not being a typical web application like Django, many of general recommendations regarding the development of safe applications still apply. For instance, studying and implementing the applicable recommendations presented by OWASP will certainly go a long way in making sure the services you develop stay safe.