You are mistaken.
There are 2 ways to handle A&A. One is for the application itself to totally handle security. This is the dangerous way. The other is to let the container handle security. This is the safer way.
The JEE standard defines the Container-Based Security System - a set of container implementation specs and API methods that allow an incoming URL to be checked BEFORE it is dispatched to the webapp, to ensure the authenticity of the requester and to forbid access to URLs for which the requester does not possess a valid security role. In other words, there is no login code in the web application itself, it's all in the server (Tomcat, WebSphere, Wildfly or whatever) and forbidden requests never reach the webapp at all. Which means that they cannot reach possibly weak spots to exploit.
Yhe container security system is configured by elements in the webapp's /WEB-INF/web.xml file or annotation equivalents and from the servlet deployment Context, but none of the primary security for the application are in application code. You can fine-tune security using certain API methods such as the HttpServletRequest isUserInRole() method, and you can get the login userId from the getRemoteUser() method, but the primary wall against unauthorized access is completely automatic and done entirely outside of the webapp by Tomcat itself.
So to make that work, you not only have to configure security elements in web.xml, you also have to define a security Realm for the webapp when it is deployed.
Technically speaking, there are two components used to deploy any JEE webapp. There's the server-independent deployment Descriptoi, whic is the web.xml file (again, or annotation equivalents). And there's the server-dependent Deployment Descriptor. The name and media/format of the server-dependent deployment descriptor is uniiquely defined by and for the implmenters of the webapp container, For Tomcat, it's the Context XML which can be located in the WAR's META-INF diretory or in the TOMCAT_HOME/conf/Catalina/localhost directory or one of several other places detailed in the Tomcat documentation.. It is this Context, or in inherited super-context from the TOMCAT_HOME/coonf/server.xml file that determines where and how to validate userid, password and security roles.
By default, no primary or inherited security context (Realm) is configured for Tomcat webapps. Normally you would do this in the Context, just as you would the Database Connection Pool specs.
So our question is, are you using that system, and if so, what kind of Realm do you have configured for it?