Generator-jhipster: i18n Security

Created on 19 Jun 2018  路  2Comments  路  Source: jhipster/generator-jhipster

Overview of the issue

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.

Motivation for or Use Case

Securing i18n Translations, as i18n translations can be used to determine the existence of features to unauthorized users.

This is a bug as the .json file is downloaded with all corresponding translation paths, risking the application

Reproduce the error

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

Related issues

Suggest a Fix

The entire www directory is publicly accessible when running the war file, consider adding access controls similar to .htaccess files

JHipster Version(s)

4.14.3

JHipster configuration

{ "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" ] } }

Entity configuration(s) entityName.json files generated in the .jhipster directory

N/A

Browsers and Operating System

N/A

  • [ X ] Checking this box is mandatory (this is just to show you read everything)

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.

All 2 comments

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.

Was this page helpful?
0 / 5 - 0 ratings