i18n is configured as an ant-matcher in the SecurityConfiguration.java, however when building for Production the entire i18n directory is available without passing through the security of the application.
Securing i18n Translations, as i18n translations can be used to determine the existence of features to unauthorized users.
This is a bug as the 
Adding in an ant-matchers to the security for example
 .antMatchers("i18n/home/**").permitAll()
 .antMatchers("i18n/dashboard/**").authenticated()
Should prevent access to the dashboard translation files from unauthorized users
The entire www directory is publicly accessible when running the war file, consider adding access controls similar to .htaccess files
4.14.3
{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "com.XXX",
      "nativeLanguage": "en"
    },
    "jhipsterVersion": "4.14.3",
    "baseName": "XXX",
    "packageName": "com.XXX",
    "packageFolder": "com.XXX",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "cacheProvider": "ehcache",
    "enableHibernateCache": true,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "postgresql",
    "prodDatabaseType": "postgresql",
    "searchEngine": "elasticsearch",
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "gradle",
    "enableSocialSignIn": false,
    "enableSwaggerCodegen": false,
    "jwtSecretKey": "a6de307e0a8f77c1cc21b824cc83ca10ed909602",
    "clientFramework": "angularX",
    "useSass": false,
    "clientPackageManager": "yarn",
    "applicationType": "monolith",
    "testFrameworks": [
      "gatling",
      "cucumber",
      "protractor"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": [
      "en",
      "de"
    ]
  }
}
entityName.json files generated in the .jhipster directoryN/A
N/A
Yes, this is a question that we get very often.
The whole front-end application is accessible without restriction, as it is ready to be published on a CDN or on a specific front-end server, which is another very common question we get from people.
As always with a front-end application, your users have access to all of it. They can even change their security role and have access to "restricted" screens.
This is normal with a single-page application, especially when it is minified and stored on a CDN. You could see JHipster as two applications, a front-end and a back-end one.
There is no security issue as long as the back-end is protected - yes you can have access to "restricted" screens on the front-end, but you won't get any data, and won't be able to perform any action on them.
If you really want a strict separation, then many people build two front-ends: one for end-users, and one that is used internally in their company. Those front-ends would not be accessible through the same networks, typically.
Closing this, as it's more a question, than an issue, and it has been answered by Julien.
Most helpful comment
Yes, this is a question that we get very often.
The whole front-end application is accessible without restriction, as it is ready to be published on a CDN or on a specific front-end server, which is another very common question we get from people.
As always with a front-end application, your users have access to all of it. They can even change their security role and have access to "restricted" screens.
This is normal with a single-page application, especially when it is minified and stored on a CDN. You could see JHipster as two applications, a front-end and a back-end one.
There is no security issue as long as the back-end is protected - yes you can have access to "restricted" screens on the front-end, but you won't get any data, and won't be able to perform any action on them.
If you really want a strict separation, then many people build two front-ends: one for end-users, and one that is used internally in their company. Those front-ends would not be accessible through the same networks, typically.