Masquer les url d'appels ajax

Hello,

Je souhaiterais votre aide pour obtenir des éclaircissements pour ce que j'aimerais faire.

En fait, j'aimerais qu'une page puisse faire un appel à un ou plusieurs serveur(s) Rest sur des urls différentes: www.siteA.com, www.siteB.com, www.siteC.com, etc.

Je suis par exemple siteA.com, et je souhaiterais faire une requête Ajax en parallèle sur siteB.com et siteC.com afin d'obtenir un retour Json de chacun d'eux.

Jusque là, pas de problème sauf que l'url que j'appel en ajax apparait en clair dans la page html. Mon souhait serait évidement que cette info n'apparaisse pas.

Je pense que c'est impossible de faire ce que je veux faire ou je me trompe?


Pour résumer, faire un appel Ajax sans que l'url d'appel ne soit visible par un humain dans le code source.

Merci de votre aide! :ccool:

Effectivement c'est impossible, un humain pourra toujours savoir quelle est l'adresse de destination d'un appel de sa part, AJAX ou pas. C'est quand même un principe de base de sécurité et de transparence de savoir avec qui on communique.

Le seul autre moyen est de passer par un serveur passerelle (généralement ton serveur web) qui lui fait la requête sur les services extérieurs.

J'y avais pensé, et c'est ce que je comptais faire à la base.

Mais si je passe par un serveur passerelle, ce sera beaucoup plus lent.

Je devrais appeler des dizaines de serveurs à la fois, et avec le serveur passerelle, je devrais executer tout d'une fois via cURL par exemple et je ne pourrais executer des requêtes ajax. Ici l'avantage était de faire des dizaines de requêtes asynchrones sur les serveurs en questions en ajax, de manière à ne pas surcharger un seul serveur et surtout de manière à toujours pouvoir travailler en attendant le résultat.

S'il ne s'agit que de code source, tu peux toujours chiffrer les URL bien sûr, mais bon ça vaut peau de balle. Quelqu'un qui sait demander le code source saura aussi demander à son navigateur à quelles URL il se connecte.

Sinon rien n'empêche de paralléliser les requêtes mêmes si elles sont toutes faites sur le même serveur : ils sont faits pour bosser en parallèle, pas en séquence. Par contre il reste le problème de la charge.

Enfin rien n'empêche de mettre des genres de proxy devant serverB et serverC, de sorte que les URL qu'on appelle dessus soient inoffensives, et que le proxy se charge de faire les vrais appels à serverB et serverC, ceux qui doivent être protégés.

Ou alors, il faut que je regarde si je peux appeler l'URL Rest de chaque serveur non pas avec www.monsiteX.com, mais avec l'ip...

Je dois me renseigner pour voir si c'est envisageable, mais ce genre de protection me suffira largement pour ce que je veux faire.

Même en passant l'IP l'utilisation d'un reverse DNS est enfantine :?

Oui tout à fait d'accord, mais ce sont des gens qui ne sont pas dans le bain, je doute déjà fort qu'il aille voir leur code source, mais je veux masquer un maximum quand même par acquis de conscience.

Je t'avoue que je sais pas trop pourquoi ta conscience te pèse quand tu laisses voir des URL et des noms de domaine. C'est pas comme l'anatomie, hein, il y a rien d'obscène.

(Enfin, sauf si tu fais des appels à http://penis.inplainview.xxx ou http://hotbreastfeeding.xxx , là effectivement je sais pas si c'est obscène mais des gens le pensent. Je comprends mieux le cas de conscience.)

De toute façon tu n'as pas le choix l'utilisateur DOIT rester maître de sa machine. ce n'est pas à toi développeur js de venir sur SA machine, te connecter depuis CHEZ LUI vers tous les HACKEUR du monde sans lui demander son avis.

Règle N° 1 le client DOIT TOUJOURS savoir vers quel site il se connecte
Règle N° 2 les connexions AJAX se font TOUJOURS vers le site de la page

Citation:

---

Envoyé par sekaijin

Règle N° 2 les connexions AJAX se font TOUJOURS vers le site de la page

---

Non ça c'est complètement faux, ça fait longtemps qu'on fait du AJAX cross-domain et ça n'a jamais tué personne :roll:

Faut pas exagérer quand même... ça ne fait pas longtemps que c'est possible et encore faut-il que le serveur distant l'accepte...
Donc je ne suis pas trop d'accord avec toi pour dire que c'est "complètement faux"...
J'aurais tendance à penser que ça reste vrai même si des solutions sont prévues pour contourner la limitation...

J'ai des applications en production depuis 3 ans qui font du AJAX cross origin resource sharing, elles tournent même sur IE8 avec XDomainRequest. Et avant ça il y avait déjà la technique d'utiliser une balise <script> ou encore du JSONP.

Alors excuse-moi mais poser ça comme règle numéro 2 en gras rouge majuscule, je trouve ça excessivement mensonger :?

Oui, mais encore une fois, tu parles du cas particulier dans lequel tu as la main sur un serveur que tu configures pour accepter les requêtes cross domaine. Dans le cas général (qui est quand même le plus courant), ce n'est pas possible.
Quant aux balise script, object et autres permettant de contourner la Same Origin Policy, il ne s'agit plus à proprement parler d'AJAX (au sens XMLHttpRequest voire XDomainRequest).

Salut

Citation:

---

j'aimerais qu'une page puisse faire un appel à un ou plusieurs serveur(s) Rest sur des urls différentes: www.siteA.com, www.siteB.com, www.siteC.com, etc.

---

Je regrette mais en lisant ça je continu à affirmer ce que j'ai dit.
il existe des solution pour contourner cette règle dans des cas bien particulier c'est sur. mais c'est comme la limitation de vitesse sur un route nationale
la règle est une route nationale est limité à 90 km/h
pourtant nous connaissons tous des tronçons de route nationale à 110km/h ou bien d'autre limitation.

Comme toujours on contourne une règle mais on bafoue la loi.

ça ne change rien au fait que SEUL le client doit garder le pouvoir sur SA navigation. tout ce qui est fait dans son dos est à juste titre à considérer comment HACK.
il en résulte que si une politique de contournement de ces règle est mise en oeuvre le client en sera informé. donc les url des site à visiter seront connue de lui.

vous autorisez les développeur de page web à connecter de façon cachée à des url invisible à l'insu des client et tous les crackeurs vont se défouler et pomper toutes vos machine pour collecter le max d'informations sur leur serveur.

Quoi que vous fassiez les urls sur lesquelles le navigateur se connecte seront toujours connues du client.

Qui n'a jamais entendu parler de scandales d'application native (d'OS) intégrant des backdoors. c'est toujours un problème et ça se détecte toujours.

alors vouloir permettre de créer des backdoors avec un simple script dans une page HTML c'est n'importe quoi.

Je dis simplement en tant que développeur faites marcher votre petite tête et réfléchissez à ce qu'implique de contourner ces règles. je ne dis pas que ce n'est pas techniquement faisable. je dis que ce sont des règles pour nous et que les contourner à une incidence que nous devons absolument connaitre. pour ne pas mettre à mal nos application.

je peux vous garantir que chez moi, si on détecte une adresse web qui fait un truc du genre le domaine est bannis du SI, la signature du code est ajouté dans le scanner du proxy et toute page qui comporte cette signature entraîne automatiquement le bannissement du domaine. et comme les domaines blacklisté sont échangés entre SI il seront bannis de nombreux SI.

donc en tant que développeur vous aurez gagné. vous avez voulu (involontairement) mettre en danger vos clients vous êtes inaccessibles.

A+JYT

Je trouve cette politique de bannissement des requetes cross-domain vraiment ridicule. C'est un besoin courant pour de nombreuses applications, et le W3C en a proposé une standardisation dès 2007.

S'il s'agit de services externes retournant du JSON, je présume qu'il s'agit de web-services correctement configurés pour la règle Access-Control-Allow-Origin, et sans doute répondant à une API RESTful. Ce n'est pas un cas particulier, je le vois sur plein de sites.

Je peux comprendre que dans certains milieux professionnels, notamment dans l'industrie, des mesures de sécurité supplémentaires doivent être appliquées. Mais quand je lis ça :

Citation:

---

vous autorisez les développeur de page web à connecter de façon cachée à des url invisible à l'insu des client et tous les crackeurs vont se défouler et pomper toutes vos machine pour collecter le max d'informations sur leur serveur.

---

c'est quand même proche de la panaroïa... Qu'il s'agisse d'AJAX cross-domain ou de serveur relais, c'est quelque-chose qui se fait depuis des années sur tout un tas de services B2B ou B2C. Et je le répète, je n'ai jamais entendu le moindre risque en matière de sécurité du moment qu'on encode et vérifie les entrées (tout comme on le ferait pour un formulaire web classique)

encore un efois il ne s'agit pas de bannir le cross domain mais de le faire en toute TRANSPARENCE

la question posé dit

Citation:

---

Mon souhait serait évidement que cette info n'apparaisse pas.

---

en clair

Citation:

---

Je veux fournir une PAGE WEB à un client qui TOUTE SEULE SANS QUE LE CLIENT NE PUISSE LE SAVOIR se connectera sur un serveur INVISIBLE.

---

ce n'est pas la même chose que

Citation:

---

Je souhaite fournir une PAGE WEB à un client qui invoquera EN TOUTE TRANSPARENCE à un web service VISIBLE et SECURISE.

---

celui qui fait le premier est banni celui qui fais le second est autorisé
je serais content de voir comment tu réagirais si quelqu'un réussissait a travers la première solution à te piquer tes infos bancaires et vider tes comptes. Ce n'est pas de la paranoïa c'est du bon sens.

imagine aussi pour un administrateur si une simple page web peu se connecter à une url interdite dans l'entreprise de façon cachée.
pourquoi crois-tu que les liste des ip des anonymiser se vendent à prix d'or ? simplement pour essayer de garantir que la politique de sécurité n'est pas mise à mal en passant au travers d'un tel proxy. (c'est une course sans fin mais elle est nécessaire)


A+JYT

Justement, les serveurs qui se connectent à d'autres web-services sans l'indiquer au client parce que l'on estime qu'il n'a pas à le savoir, c'est quelque-chose de très courant. Mon projet professionnel actuel repose sur ce principe : on se sert de plusieurs services internes et externes à l'entreprise, sur des domaines différents, pour récupérer diverses informations et les traiter pour aboutir à une réponse sérialisée en JSON et renvoyée au client.

Dans tous les cas le problème est le même, c'est la relation de confiance que tu as avec le service en question. Mais sachant que le service peut appeler tout et n'importe quoi comme service tiers de son côté (càd. invisible au client), et que ça se fait depuis les débuts d'Internet, qu'est-ce qu'il y a de mal à vouloir le faire côté client en AJAX, là où justement le client a plus de visibilité sur les requêtes ?

A te lire, on croirait que ce sont les utilisateurs finaux qui sont en charge de la politique de sécurité de ton application. C'est encore au développeur du service de savoir ce qu'il fait et d'engager sa responsabilité sur la fiabilité des différents services externes auxquels il fait appel.

Ce n'est pas du tout la même chose

si tu utilise le site web SNCF pour les horaires de train
la page web que tu ouvre va se connecter sur un service de la sncf
en tant que client tu lui fait confiance ou pas c'est ton problème.
si le service de la SNCF de son côté agrégé des chose qui viennent d'ailleurs toi ce que tu vois en tant que client c'est le service de la SNCF et tu peux décider si oui ou non tu lui fait confiance.

mais cette page ne va pas de façon totalement caché aller se connecter sur un service inconnu pour lui envoyer des infos que tu ne maîtrise pas et dont tu ne peux rien savoir.

Si pour afficher ton itinéraire ta page de la SNCF fait appel à une carte openstreetmap, google-map ou autre ton navigateur te permettra en tant que client de connaitre l'url du service de cartographie et c'est normal.

Je dis qu'il ne faut pas le lui cacher car il en va de sa sécurité.
imagine que tu n'ai pas accès en tant que client à cette url.
tu ouvre ta page itinéraire SNCF et une carte s'affiche, tu reconnais le tracé de google map et tu te dit tout est OK. tu veux vérifier et là impossible de savoir d'où vient la carte car les urls (comme le demande Sayrus) sont toutes cachées. tu peux continuer à faire confiance. mais rien ne te dis qu'en fait tes info sont envoyé à de fin fallacieuse à un service qui lui te retourne un carte google map. si au contraire tu as l'url en tant que client tu peux décider si oui ou non le service est digne de confiance.

Si maintenant c'est le service de la SNCF qui fait l’agrégation côté serveur en tant que client tu sais que tu accède au servce de la SNCF puisque tu vois son url. là encore c'est à toi de décider si tu lui fait confiance. mais si la page web pouvait cacher les url (comme le demande Sayrus) tu ne sais plus à quel service tu accède. tu n'as donc aucun moyen de décide si tu peux faire confiance à une chose que tu ne connait pas et ne peut pas connaitre.

lorsque tu mets en oeuvre

Citation:

---

les serveurs qui se connectent à d'autres web-services sans l'indiquer au client parce que l'on estime qu'il n'a pas à le savoir, c'est quelque-chose de très courant.

---

tu définis un service que tu offre à ton client et pour que celui-ci accepte de te faire confiance il te faut lui fournir les argument adéquats, voire signer un engagement (tu t'engage à ne pas exploiter... ni revendre .... dans es cadre de ....)
Ton client n'a donc pas à savoir sur quoi se branche ton serveur mais pour lui vendre ton service tu lui apporte des garantie.


ce que demande Sayrus c'est que la page web elle-même donc le poste du client lui-même puisse se connecter de façon caché sur un service invisible.

lorsque toi tu connecte ton serveur à d'autres services tu prends des précautions et mets en oeuvre une politique de sécurité.

Mais si tu autorise les page web à se connecter n'importe de façon cachée, le poste du client se retrouve de fait à se connecter à des service sans aucune sécurité.

Lorsque tu connecte ton serveur à d'autres services tu offre à ton client un service intégré c'est du same origin policy. s'il estime que ton service n'est pas assez sur il te banni et c'est fini.

lorsque une page web se connecte à plusieurs service c'est du multi origin policy. là le navigateur averti le client et lui indique quelles sont les url auquelles la page veut se connecter. s'il estime que toutes ses url son sure il peut accepter les services.

Si comme le demande Sayrus une page web se connecte à plusieurs service de façon caché c'est du multi origin policy. Mais comme les url sont invisibles (c'est encore une fois ce qui est demandé) Il n'est pas question d'avertir le client pour les autoriser. du coup le client ne peux plus décider si oui ou non il fait confiance.



tu peux si tu veux avec chromium te builder un navigateur qui accepte tous les cross domain i.e. il autorise toutes les connexion par défaut.
car faire ce que demande Sayrus ça revient à ça. je pense que si tu mets un tel navigateur sur le marché en annonçant à ceux qu'il cherche un navigateur alternatif que pour leur facilité la vie et éviter les demande de sécurité ton navigateur laisse tout passer, il ne sera pas beaucoup déployé (il y a toujours des curieux) et rapidement les antivirus et anti spyware le considéreront comme dangereux.


encore une fois je ne dis pas qu'il ne faut pas faire du cross domain.
je dis que si on le fait il est normal qu'il en soit informé.

si on veux cacher les services on fait ça côté serveur et on n'a plus de cross domain.

Citation:

---

A te lire, on croirait que ce sont les utilisateurs finaux qui sont en charge de la politique de sécurité de ton application. C'est encore au développeur du service de savoir ce qu'il fait et d'engager sa responsabilité sur la fiabilité des différents services externes auxquels il fait appel.

---

tu n'a pas bien lu la demande il ne s'agit pas d'une application il s'agit d'une page web. le client n'installe rien de son propre chef. il clique sur un lien en navigant et hop la page affiché fait n'importe quoi dans son dos. il ne s'agit pas d'assurer la sécurité de ton application. il s'agit d'autoriser de façon caché un poste client à se connecter n'importe où sans que l'utilisateur ne le sache sans qui ait installé quoi que ce soit juste visité un site web.
le client s'en moque de la sécurité de ton appli si tu ouvre un trou, un gouffre comme celui-là sur son poste.


je ne vois pas ce qu'il a de compliqué la dedans. mettre en place une techno qui permet à une page web sur le poste de n'importe qui de se connecter n'importe ou en cachant totalement à l'utilisateur ces connexions, c'est la porte ouverte au piratage massif.

alors la sécurité de ta petite application mais face à un tel problème ton client il s'en moque.


Je le répète encore une fois la demande de Sayrus est de permettre à une page web sur le poste du client d'accéder a des url de façon caché
j'insiste il s'agit de simple page web
j'insiste il s'agit de poste du client
j'insiste il s'agit d'url de façon caché

il n'y a là pour le client aucune sécurité

A+JYT

Citation:

---

Envoyé par sekaijin

lorsque toi tu connecte ton serveur à d'autres services tu prends des précautions et mets en oeuvre une politique de sécurité.

Mais si tu autorise les page web à se connecter n'importe de façon cachée, le poste du client se retrouve de fait à se connecter à des service sans aucune sécurité.

---

C'est sur ce point que nous ne sommes pas d'accord. Pour moi la politique de sécurité d'un site web (ou d'une application, la frontière entre les deux étant de plus en plus mince) se fait sur toute la chaîne, c'est-à-dire autant sur le poste du client que sur la partie serveur. On prendra autant de précautions à utiliser un service tiers côté serveur que côté client.

De toute manière comme dit au début de ce topic, il est impossible de masquer complètement les URL d'appels AJAX. Et j'ai surtout tiqué sur

Citation:

---

Envoyé par sekaijin

Règle N° 2 les connexions AJAX se font TOUJOURS vers le site de la page

---

mais si tu es d'accord pour dire que l'on peut faire de l'AJAX cross-domain, alors ça me va :)

comme je l'expliquais c'est une règle pour le développeur ce n'est pas une contrainte technique

si tu la prends comme tel
tu sais que tu n'a pas de problème de sécurité particulier à géré sur le poste du client (autre que l'acces web habituel)

du coup le jour où tu doit contourner la règle, que ton besoin t’amène à envisager du cross domain, le fait d'invalider la règle t'alerte sur le fait que tu auras potentiellement des problèmes de sécurité à gérer.

c'est comme un zone sécurisé avec un garde à l'entrée. il y a bien un porte annexe qui permet d'entrer ou de sortir mais la règle dit
on passe toujours par le poste de garde, l'usage de la porte annexe est interdit.

le jour où tu dois faire entre un truc dans ta zone qui physiquement ne peux pas passer par le poste de garde. tu te dis il y a bien la porte annexe mais si elle est interdite c'est pour une bonne raisons et tu fais ton travail côté sécurité pour savoir ce que ça implique de l'ouvrir.

si tu ne mets pas de règle de sécurité sur la porte annexe elle finira par être ouverte sans précaution.
ce n'est pas la règle qui assure la sécurité de ta porte annexe. la règle n'est qu'un outil pour t'alerter le jour où il faut l'ouvrir.

pour moi la règle n°2) c'est exactement ça. tu l'applique tu travail en toute sécurité sans trop te poser de question. tu ne peux plus l'appliquer alors tu dois te questionner sur les implications.



pour moi aussi la sécurité c'est sur tout la chaîne. je disais juste que si tu ouvre au quatre vents le SI de ton client il s'en fout que tu n'ai pas bien sécurisé ton serveur. si par contre tu lui permets d'assurer la sécurité de son SI il sera concerné par tout la chaîne de sécurité de ton application.

A+JYT

Ce n'est pas une règle, c'est un besoin. Soit tu as besoin de services tiers, soit tu n'en as pas besoin. Et si tu en as besoin, que tu les appelles depuis le serveur ou depuis le client, cela ne change rien aux précautions de sécurité à prévoir. Tu as besoin d'une nouvelle porte, tu embauches un nouveau garde. C'est aussi simple que ça.

encore une fois ce n'est pas sur la liaisons avec des tiers ou quoi que ce soit en tant que besoin que pour moi il est nécessaire de définir ce genre de règles.

il y a dans la boîte des centaines de développeurs. lorsqu'on en embauche un nouveau. on ne le laisse pas dans la nature à faire ce qu'il veux.

indépendament de tout cahier des charche de tout travail à réaliser, on lui donne un ensemble de règle à suivre pour que sont travail en adequation avec celui de ces colègues, pour que la qualité de sont travail ait le niveau souhaité par la boite, mais aussi pour lui faciliter la vie.

il y a dans toutes ces règles des choses qui font bondir. car on ce dit si je ne peux pas faire ça quand je serait confronté à ... comment je vais faire. et là déjà la règle fait preuve de son efficacité. elle oblige le développeur à réflechir.

cette règle n'a pas d'autre but. tu entre dans la boit tu suis cette règle et tu n'as pas à te poser trop de question.
un beau jours une demande d'un client arrive et là te ne vois pas d'autre solution que de contourner la règle. du coup vu que tu contourne une règle tu sais que tu n'es plus dans le scope habituel et qui faut y aller avec prudence. tu sais que ce que tu fais habituellement n'est peut être pas suffisent pour la robustesse, l'efficacité, la sécurité ... et c'est la nature de la règle que tu cherche à contourner qui t'indique sur quel dommaine il te faut être vigilent.

même si je travaille dans un domaine ou les échelles sont grandes (100 000 à 200 000 personnes) je pense que s'appliquer à soit, ce genre de règles permets d'avoir des garde fou et de se facilité la vie.

A+JYT

Tu utilises beaucoup d'exemples et d'analogies, mais elles me semblent toutes hors-sujet.

Ce que je constate, c'est que j'ai dû faire du AJAX cross-domain dans trois de mes projets professionnels. Aujourd'hui, je bosse sur une web-app hybride avec Apache Cordova, qui tourne donc sur localhost et doit de fait faire du CORS pour appeler nos services externes. Je ne peux pas faire autrement, c'est un besoin. Même si je m'imposais une règle de toujours passer par un seul serveur sous mon contrôle, ce ne serait pas à moi d'en décider. De plus, centraliser les appels de services tiers sur mon serveur entraînera plus de latence (ce qui est critique quand il s'agit de web mobile) et plus de consommation de ressources serveur de mon côté. On y gagne beaucoup à faire ces appels côté client, et c'est entièrement sécurisé (pas d'évaluation de code externe, juste des échanges data sérialisés). Je fais ça depuis trois ans et je suis loin d'être le seul dans ma boîte (qui pour info est le leader français du paiement en ligne, donc on est pas les plus mauvais question sécurité).

Donc contrairement à ce que tu t'entêtes à penser, on peut parfaitement sécuriser de l'AJAX cross-domain et ça nous facilite la vie. Après, si tu veux rester sur tes principes de précaution et refuser d'aller en avant, c'est ton choix, mais ne va pas faire de la désinformation et faire peur aux gens avec des histoires de crackers/hackers... Je pense avoir tout dit, à chacun d'en tirer ses conclusions :ccool:

je crois que je vais abandonner

Je n'ai jamais dit qu'il ne fallait pas le faire.
Je ne dis pas qu'on ne peut pas le sécuriser.
Je ne dis pas que ce n'est pas un besoin.
Je ne parle pas de technologie
Je ne parle pas d'AJAX.


Je parle d'organiser le travail.
Je parle de mettre en place des moyens pour que le développeur reste conscient
Je parle de moyen pour alerter le développeur sur ce qu'il fait

Cette règle est exactement du même acabit que
"Il faut indenter son code"
"Il faut documenter son code"
"Il faut veiller à tester toutes les fonctions"
etc.

Tout ça n'a rien à voir avec la techno
Ce sont des règles de travail pour le développeur, pas pour ce qu'il développe.
Avoir de telles règles aide à travailler.

Tu dis que ma règle t'a fait bondir
Je te réponds que tu l'interprètes mal. Elle ne dit pas que techniquement tu ne peux pas le faire, elle ne dit pas que techniquement tu ne dois pas le faire. Elle dit : abstiens-toi, autant que possible, de le faire. et elle le dit de façon impérative non pas pour t'empêcher de le faire, mais simplement pour que tu te dises "mince, cette fois je ne peux pas appliquer cette règle, il faut que je fasse gaffe à ce que je fais"


je dis amis développeur applique cette règle Règle N° 2 les connexions AJAX se font TOUJOURS vers le site de la page et tu ne seras pas embêté par les problèmes de sécurité cross domain
Si un jour tu devais l'enfreindre cette règle alors pose toi toutes les questions concernant la sécurité du poste de ton client.


A+

C'est sûr que si l'on entreprend rien, on évite les problèmes. Cela demande un peu plus de travail donc ne le fais pas sauf si on t'y oblige. En voilà un bon conseil pour les développeurs...

Citation:

---

Envoyé par sekaijin

Règle N° 2 les connexions AJAX se font TOUJOURS vers le site de la page

---

Citation:

---

Envoyé par sekaijin

Je ne parle pas d'AJAX.

---

:roll:

je me suis remis au Javascript récemment, venant d'un background plutot entreprise. Je trouve qu'il y a beaucoup d'a priori au sujet du langage. Les Frameworks ont évolué (il ne faut pas s'arreter a JQuery) et les applications mono pages offrent une alternative a des méthodes serveurs inutiles.

Je pense qu'au pire tu peux:

- minifier avec YUI compressor ou Uglify
- obfuscation (des chaînes de caratères)

il me semble qu'une console Chrome / Firebug affichera tout de même tes connections GET, POST

edit: en ce moment j'utilise une librairie qui demande du "reflection". Si tu minifie ton code, la librairie ne pourra pas reconnaitre certains objets

je l'ai dis ce n'est pas impossible tu peux trouver des moyen de masquer des chose
http://www.developpez.net/forums/d13...e/#post7355854

Mais comme dans ce post faire ça sera considéré à juste titre comme une volonté de piratage.

ou encore tu peux faire ça
http://www.developpez.net/forums/d13...ighlight=trois

mais là encore un resp de sécurité qui voit ça va penser que c'est une tentative de piratage

A+JYT