Sécurisez un REST api accessible au public
Nous construisons une application publique d'une seule page en JavaScript qui communique avec un service principal REST service. Ce que nous voulons, c'est que ce service REST ne soit accessible qu'à partir de l'application d'une seule page.
Puisqu'il s'agit d'un site Web public, nous ne pouvons pas/ne voulons pas que l'utilisateur entre les détails d'authentification. Tout mécanisme d'authentification normal ne fonctionnera pas non plus car tous les secrets stockés dans JS sont lisibles par quiconque.
Je pense qu'il est impossible de sécuriser le service REST, car il doit essentiellement être public, mais je me demandais si quelqu'un avait une idée de la façon dont vous empêcheriez quelqu'un de créer un script et de reproduire notre application en utilisant notre REST api.
La première pensée qui vous vient à l'esprit est d'utiliser des sessions ou de configurer quelque chose sur votre page pour enregistrer les IP des connexions entrantes et autoriser uniquement l'API REST à répondre aux IP qui ont récemment accédé à votre principal Cela n'empêchera pas tous les cas, mais cela signifie que quelqu'un doit au moins accéder périodiquement au site principal pour utiliser l'API REST.
Fondamentalement cependant, si les utilisateurs ne sont pas tenus de s'authentifier, rien n'empêche un ripper d'écran d'extraire efficacement les données de votre site. Les règles métier doivent être appliquées par l'API REST et donc l'API REST doit être effectivement votre site Web et la page l'utilisant doit simplement fournir une mise en forme pour le afficher.
S'il s'agit d'applications natives, vous pouvez essayer ce qui suit,
- Stockez une clé d'accès dans votre ensemble d'applications. Personne d'autre que le propriétaire de l'application (vous-même) ne peut avoir cela.
- Modifiez votre API afin que seules les demandes avec la clé d'accès définie dans l'en-tête aboutissent.
- Utilisez HTTPS pour que personne ne puisse lire la clé d'accès chiffrée.
Si vous n'utilisez pas HTTPS, vous pouvez toujours hacher manuellement la clé d'accès avec quelque chose dans l'en-tête (seule la logique de votre serveur et de votre application le sait) afin que l'homme du milieu ne puisse pas prétendre être votre application.
Si c'est pour des applications Web pures,
Je suggérerais d'abord d'envelopper l'application Web pure dans une application native (a.k.a. Hybrid app) afin que vous puissiez obtenir la protection décrite ci-dessus, en regroupant une clé secrète dans l'application. Développer une application native avec une seule vue Web à l'intérieur ne devrait pas coûter trop cher.
Cependant, si cela n'est pas possible, votre application reste donc une pure application Web - voici une option potentielle,
- Lorsque le serveur dessert l'application Web, fournissez une clé d'accès.
- Lorsque l'application Web effectue un appel API, elle doit fournir une version hachée de la clé d'accès.
- Le hachage de votre application Web dépend de la logique implémentée dans les codes minifiés + obscurcis.
- Votre API dorsale valide ensuite le hachage en appliquant la même logique cachée à la clé d'accès stockée pour calculer le hachage et voir s'il correspond.
- Vous pouvez modifier la logique cachée et la clé d'accès aussi souvent que nécessaire pour réduire les chances que quelqu'un obtienne le bon hachage.
Ce n'est bien sûr pas à l'épreuve des balles mais comme vous le savez, il n'y a pas de sécurité parfaite et cela atteint probablement l'objectif (et, espérons-le, correspond au projet de loi). Je dirais cependant que l'hybridation est plus rentable.
Cela pourrait aider. Il existe de nombreux moyens de sécuriser votre service de repos. L'un est CORS et utilise PUT/Delete car ces en-têtes ne peuvent pas être définis entre domaines. http://www.nsa.gov/ia/_files/support/guidelines_implementation_rest.pdf