HTTP(S) caching is defined in RFC 7234; there is not currently any superseding document, so this is what you should refer to.
no-cache response directive is a bit of a misnomer. It doesn't prohibit caching a document. It allows caching a document, but it is immediately considered stale and must be revalidated with the origin server before being used. You'll note that this is exactly the same semantics as
max-age=0, must-revalidate. In both cases, the content is cached, and if the server sends a 304 response to a validation request, the cached document can be used.
To actually request a cache to not cache a document, you would use
no-store. In this case it is not even strictly necessary to specify
no-cache as the document would not be cached anyway! But this can be much slower than
no-cache alone, as the document must be re-downloaded in its entirety every time the user accesses it.
Perhaps the fact that one of the
Cache-Control directives you used as examples did not contain
no-store is what your seniors were referring to, though calling this a "vulnerability" is severely overstating the matter, and whether it's a security (though again this is usually privacy) issue depends on the content you're serving.
In most contexts where you are sending user-specific information it is sufficient to set
Cache-Control: private and allow the user's browser to cache the data, while shared caches will not cache it. I can't think of much that really needs to be
no-stored, except perhaps private keys, nuclear launch codes, data that changes every 15 seconds, etc...