Comment restreindre l'API AJAX contre une utilisation indésirable (p. Ex., Quelqu'un qui effectue un SELECT *)

J'ai une application Web de restaurant local qui détruit l'emplacement des restaurants sur Google Maps.

J'utilise les curseurs JQuery pour limiter le montant du restaurant à afficher sur la carte en ayant un filtre de recherche tel que: prix, type de nourriture, localisation.

Ces curseurs JQuery rappellent via AJAX à une API que j'ai créée pour mettre à jour la carte sans que la page Web ne soit actualisée.

JQuery appelle une API RESTFUL comme ça:

http://example.com/search/?city=NYC&max-price:50&cuisine=french 

Cela renvoie une chaîne de restaurants JSON qui correspond à ce critère afin que mon application Web puisse afficher sur la carte tous les restaurants qui correspondent à la recherche.

Ce que je ne veux pas arriver, c'est que quelqu'un vienne et découvre mon API et efface TOUTES mes listes de restaurants.

Est-ce que je peux limiter qui appelle l'API HTTP ci-dessus, de sorte que seul mon serveur Web appelle l'URL et pas les spams / pirates qui cherchent à jeter ma base de données?

Merci

D'abord, déclarez vos intentions dans robots.txt .

Ensuite, envoyez un en-tête Set-Cookie avec un nonce ou une sorte d'ID unique sur la page principale, mais pas sur vos réponses API. Si le cookie n'est jamais envoyé à votre point final d'API, renvoyez une réponse 401 Bad Request , car c'est un robot, un navigateur très cassé ou quelqu'un rejette vos cookies. L'en-tête de référence peut également être utilisé comme un contrôle supplémentaire, mais il est banal de faux. Respectez le nombre d'appels API effectués par cette ID. Vous pouvez également faire correspondre les identifiants aux adresses IP. Si elle dépasse votre seuil, crachez une réponse 403 Forbidden . Rendez votre seuil suffisamment élevé pour que les utilisateurs légitimes ne soient pas capturés par elle.

Gardez de bonnes journaux et mettez en surbrillance 401 et 403 réponses.

De façon réaliste, si quelqu'un est assez déterminé, ils pourront décharger cette information. Votre but ne devrait pas être de rendre cela impossible, car vous ne réussirez jamais. (Voir tous les adieux habituels sur la réalisation d'une sécurité parfaite.) Au lieu de cela, vous voulez bien préciser que:

  • Ce comportement est contraire aux termes du service.
  • Vous essayez activement d'éviter cela.
  • Vous savez que le délinquant existe et à peu près qui ils sont.
  • Des avocats effrayants pourraient commencer à s'immiscer si cela continue.

(Vous avez un avocat, n'est ce pas?)

Pour ce faire, assurez-vous que le corps de votre réponse 403 Forbidden transmet un message de sonde effrayant selon les lignes de "Cette demande dépasse l'utilisation maximale autorisée de l'API. Votre adresse IP a été enregistrée. Veuillez vous référer aux termes du service et à l'obéissance Les directives dans robots.txt . "

IANAL, mais je crois que le DMCA peut être appliqué dans cette situation si vous réclamez des droits d'auteur sur votre base de données. Cela signifie essentiellement que, si vous pouvez suivre l'utilisation illégale de votre API sur une adresse IP, vous pouvez envoyer un fichier Nastygram à leur FAI. Cela devrait toujours être un dernier recours, bien sûr.

Je n'encourage pas l'utilisation de clés / jetons d'API attribués parce qu'ils se révèlent être une barrière à l'adoption et une sorte de douleur dans le cou à gérer. En contrepoint à la réponse de @ womp, Google s'éloigne lentement de son utilisation. En outre, je ne pense pas qu'ils s'appliquent réellement dans ce cas, car il semble que votre «API» ressemble plus à un appel JSON utilisé principalement sur votre propre site.

Toutes les grandes API de REST ont tendance à utiliser l'authentification tokenized – essentiellement avant de faire une demande REST, vous devez envoyer une autre demande au service token pour récupérer un jeton à inclure avec votre demande de données. Bing Maps fait cela, Amazon fait cela, Flickr le fait … etc.

Je ne connais pas trop cela en plus d'avoir travaillé avec Bing Maps. Vous devrez lire sur l'authentification tokenized avec REST. Voici un article sur le blog pour vous aider à démarrer: http://www.naildrivin5.com/daveblog5000/?p=35