In article ,
Paul Gaborit wrote:Le simple fait que vous ne voyez pas la différence entre la solution à
base de 'eval' et celles basées sur un switch ou une recherche dans un
tableau associatif montre que la solution à base de 'eval' est
dangereuse... puisque vous ne mesurez pas correctement les risques de
son utilisation.
donc il faut être certain de tout savoir avant de se lancer à écrire
quelque chose ?
la seule différence entre la version switch et la version eval
c'est l'existence de la fonction
mais je ne demande pas mieux que d'apprendre , les forum ne sont-ils
pas fait pour ça ?
donc expliquez moi où est le danger en javascript ( hors php )
le cross-site scripting n'utilise pas que du javascript
il renvoie des donnés de forme à des script php
In article <wt9oc0mg42f.fsf@enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Le simple fait que vous ne voyez pas la différence entre la solution à
base de 'eval' et celles basées sur un switch ou une recherche dans un
tableau associatif montre que la solution à base de 'eval' est
dangereuse... puisque vous ne mesurez pas correctement les risques de
son utilisation.
donc il faut être certain de tout savoir avant de se lancer à écrire
quelque chose ?
la seule différence entre la version switch et la version eval
c'est l'existence de la fonction
mais je ne demande pas mieux que d'apprendre , les forum ne sont-ils
pas fait pour ça ?
donc expliquez moi où est le danger en javascript ( hors php )
le cross-site scripting n'utilise pas que du javascript
il renvoie des donnés de forme à des script php
In article ,
Paul Gaborit wrote:Le simple fait que vous ne voyez pas la différence entre la solution à
base de 'eval' et celles basées sur un switch ou une recherche dans un
tableau associatif montre que la solution à base de 'eval' est
dangereuse... puisque vous ne mesurez pas correctement les risques de
son utilisation.
donc il faut être certain de tout savoir avant de se lancer à écrire
quelque chose ?
la seule différence entre la version switch et la version eval
c'est l'existence de la fonction
mais je ne demande pas mieux que d'apprendre , les forum ne sont-ils
pas fait pour ça ?
donc expliquez moi où est le danger en javascript ( hors php )
le cross-site scripting n'utilise pas que du javascript
il renvoie des donnés de forme à des script php
Le risque général lié à 'eval' (dans tous les langages) est de rompre la
frontière entre code et donnée (un 'eval' transforme une donnée en du
code exécutable). Il ne suffit pas de savoir qu'à un moment donnée la
donnée passée à 'eval' est inoffensive pour se dédouaner, il faut
pouvoir prouver que c'est bien le cas quelles que soient les données
reçues et même lorsqu'on fera évoluer le code.
Pourquoi toujours tout ramener vers PHP ? Les risques que j'évoque n'ont
pas de lien avec le côté serveur (qu'il soit écrit en PHP, en Basic ou
en même en Cobol importe peu).
Le risque général lié à 'eval' (dans tous les langages) est de rompre la
frontière entre code et donnée (un 'eval' transforme une donnée en du
code exécutable). Il ne suffit pas de savoir qu'à un moment donnée la
donnée passée à 'eval' est inoffensive pour se dédouaner, il faut
pouvoir prouver que c'est bien le cas quelles que soient les données
reçues et même lorsqu'on fera évoluer le code.
Pourquoi toujours tout ramener vers PHP ? Les risques que j'évoque n'ont
pas de lien avec le côté serveur (qu'il soit écrit en PHP, en Basic ou
en même en Cobol importe peu).
Le risque général lié à 'eval' (dans tous les langages) est de rompre la
frontière entre code et donnée (un 'eval' transforme une donnée en du
code exécutable). Il ne suffit pas de savoir qu'à un moment donnée la
donnée passée à 'eval' est inoffensive pour se dédouaner, il faut
pouvoir prouver que c'est bien le cas quelles que soient les données
reçues et même lorsqu'on fera évoluer le code.
Pourquoi toujours tout ramener vers PHP ? Les risques que j'évoque n'ont
pas de lien avec le côté serveur (qu'il soit écrit en PHP, en Basic ou
en même en Cobol importe peu).
In article ,
Paul Gaborit wrote:Le risque général lié à 'eval' (dans tous les langages) est de rompre la
frontière entre code et donnée (un 'eval' transforme une donnée en du
code exécutable). Il ne suffit pas de savoir qu'à un moment donnée la
donnée passée à 'eval' est inoffensive pour se dédouaner, il faut
pouvoir prouver que c'est bien le cas quelles que soient les données
reçues et même lorsqu'on fera évoluer le code.
toutes les fonctions d'un langage , pas seulement eval ,
font appel à du code machine que ce soit par compilation
ou par interprétation et traites des données en mémoire vive
avec même parfois du code auto-transformable ( déconseillé )
on va se passer de tout pour éviter les problèmes de sécurité ?
eval transforme une donnée en code
javascript est compilé ?
Pourquoi toujours tout ramener vers PHP ? Les risques que j'évoque n'ont
pas de lien avec le côté serveur (qu'il soit écrit en PHP, en Basic ou
en même en Cobol importe peu).
tous les risques dont on me parle font référence à un traitement sur le
serveur , le fait de dire php n'est qu'un raccourci facile
In article <wt9tyadomt0.fsf@enstimac.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Le risque général lié à 'eval' (dans tous les langages) est de rompre la
frontière entre code et donnée (un 'eval' transforme une donnée en du
code exécutable). Il ne suffit pas de savoir qu'à un moment donnée la
donnée passée à 'eval' est inoffensive pour se dédouaner, il faut
pouvoir prouver que c'est bien le cas quelles que soient les données
reçues et même lorsqu'on fera évoluer le code.
toutes les fonctions d'un langage , pas seulement eval ,
font appel à du code machine que ce soit par compilation
ou par interprétation et traites des données en mémoire vive
avec même parfois du code auto-transformable ( déconseillé )
on va se passer de tout pour éviter les problèmes de sécurité ?
eval transforme une donnée en code
javascript est compilé ?
Pourquoi toujours tout ramener vers PHP ? Les risques que j'évoque n'ont
pas de lien avec le côté serveur (qu'il soit écrit en PHP, en Basic ou
en même en Cobol importe peu).
tous les risques dont on me parle font référence à un traitement sur le
serveur , le fait de dire php n'est qu'un raccourci facile
In article ,
Paul Gaborit wrote:Le risque général lié à 'eval' (dans tous les langages) est de rompre la
frontière entre code et donnée (un 'eval' transforme une donnée en du
code exécutable). Il ne suffit pas de savoir qu'à un moment donnée la
donnée passée à 'eval' est inoffensive pour se dédouaner, il faut
pouvoir prouver que c'est bien le cas quelles que soient les données
reçues et même lorsqu'on fera évoluer le code.
toutes les fonctions d'un langage , pas seulement eval ,
font appel à du code machine que ce soit par compilation
ou par interprétation et traites des données en mémoire vive
avec même parfois du code auto-transformable ( déconseillé )
on va se passer de tout pour éviter les problèmes de sécurité ?
eval transforme une donnée en code
javascript est compilé ?
Pourquoi toujours tout ramener vers PHP ? Les risques que j'évoque n'ont
pas de lien avec le côté serveur (qu'il soit écrit en PHP, en Basic ou
en même en Cobol importe peu).
tous les risques dont on me parle font référence à un traitement sur le
serveur , le fait de dire php n'est qu'un raccourci facile
À (at) Sat, 23 Jul 2011 06:18:30 +0200,
mb écrivait (wrote):
> on va se passer de tout pour éviter les problèmes de sécurité ?
Ai-je dit qu'on devait se passer "de tout" ?
> eval transforme une donnée en code
> javascript est compilé ?
Encore une fois, quel rapport ?
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.
<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
À (at) Sat, 23 Jul 2011 06:18:30 +0200,
mb <alfred-bitller@orange.fr> écrivait (wrote):
> on va se passer de tout pour éviter les problèmes de sécurité ?
Ai-je dit qu'on devait se passer "de tout" ?
> eval transforme une donnée en code
> javascript est compilé ?
Encore une fois, quel rapport ?
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.
<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
À (at) Sat, 23 Jul 2011 06:18:30 +0200,
mb écrivait (wrote):
> on va se passer de tout pour éviter les problèmes de sécurité ?
Ai-je dit qu'on devait se passer "de tout" ?
> eval transforme une donnée en code
> javascript est compilé ?
Encore une fois, quel rapport ?
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.
<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
À (at) Sat, 23 Jul 2011 06:18:30 +0200,
mb écrivait (wrote):
> on va se passer de tout pour éviter les problèmes de sécurité ?
Ai-je dit qu'on devait se passer "de tout" ?
> eval transforme une donnée en code
> javascript est compilé ?
Encore une fois, quel rapport ?
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.
<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
À (at) Sat, 23 Jul 2011 06:18:30 +0200,
mb <alfred-bitller@orange.fr> écrivait (wrote):
> on va se passer de tout pour éviter les problèmes de sécurité ?
Ai-je dit qu'on devait se passer "de tout" ?
> eval transforme une donnée en code
> javascript est compilé ?
Encore une fois, quel rapport ?
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.
<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
À (at) Sat, 23 Jul 2011 06:18:30 +0200,
mb écrivait (wrote):
> on va se passer de tout pour éviter les problèmes de sécurité ?
Ai-je dit qu'on devait se passer "de tout" ?
> eval transforme une donnée en code
> javascript est compilé ?
Encore une fois, quel rapport ?
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.
<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
<script>
texte
</script>
que croyez vous que fait l'interprète javascript ?
tout simplement un eval("texte")
quand vous écrivez
<script url="adresse"></script>
que croyez vous que fait l'interprète javascript ?
il charge le texte du fichier adresse et fait un eval(texte)
que croyez vous que fait l'interprète javascript sur un
onClick="texte"; ?
eval(texte)
Javascript n'est rien d'autre que sa propre fonction eval
> javascript est compilé ?Encore une fois, quel rapport ?
je ne fais que reprendre votre affirmation
et elle est fausse , javascript est interprété et donc ne change pas le
texte en code , il interprète le texte ( un peu comme la version switch
dont on parlait )
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
je résume : javascript interprète du texte et il faut donc faire
attention à son encodage
le risque d'erreur dont parle ce site concerne la confusion entre des
écritures de chaînes dans divers encodages
les erreurs générées sont des erreurs Javascript et n'ont rien à voir
avec la sécurité
mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
<script>
texte
</script>
que croyez vous que fait l'interprète javascript ?
tout simplement un eval("texte")
quand vous écrivez
<script url="adresse"></script>
que croyez vous que fait l'interprète javascript ?
il charge le texte du fichier adresse et fait un eval(texte)
que croyez vous que fait l'interprète javascript sur un
onClick="texte"; ?
eval(texte)
Javascript n'est rien d'autre que sa propre fonction eval
> javascript est compilé ?
Encore une fois, quel rapport ?
je ne fais que reprendre votre affirmation
et elle est fausse , javascript est interprété et donc ne change pas le
texte en code , il interprète le texte ( un peu comme la version switch
dont on parlait )
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.
<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
je résume : javascript interprète du texte et il faut donc faire
attention à son encodage
le risque d'erreur dont parle ce site concerne la confusion entre des
écritures de chaînes dans divers encodages
les erreurs générées sont des erreurs Javascript et n'ont rien à voir
avec la sécurité
mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
<script>
texte
</script>
que croyez vous que fait l'interprète javascript ?
tout simplement un eval("texte")
quand vous écrivez
<script url="adresse"></script>
que croyez vous que fait l'interprète javascript ?
il charge le texte du fichier adresse et fait un eval(texte)
que croyez vous que fait l'interprète javascript sur un
onClick="texte"; ?
eval(texte)
Javascript n'est rien d'autre que sa propre fonction eval
> javascript est compilé ?Encore une fois, quel rapport ?
je ne fais que reprendre votre affirmation
et elle est fausse , javascript est interprété et donc ne change pas le
texte en code , il interprète le texte ( un peu comme la version switch
dont on parlait )
non : tous les risques ne reposent pas sur des défauts côté serveur...
L'URL donné plus haut décrit des risques indépendants du serveur.<http://en.wikipedia.org/wiki/JSON#JavaScript_eval.28.29>
je résume : javascript interprète du texte et il faut donc faire
attention à son encodage
le risque d'erreur dont parle ce site concerne la confusion entre des
écritures de chaînes dans divers encodages
les erreurs générées sont des erreurs Javascript et n'ont rien à voir
avec la sécurité
> Javascript n'est rien d'autre que sa propre fonction eval
Et alors ?
Les fonctions de type 'eval' n'existent que dans les langages
interprétés (Ex: PHP, Perl, Python, Javascript, Lisp, etc.).
la plupart ne sont plus depuis longtemps interprétés mais plutôt
semi-compilés (voire même compilés au vol).
Et pourtant toutes les règles de bonnes pratiques de programmation
déconseille l'usage de ces fonctions 'eval'. Cette règle n'a donc rien à
voir avec la nature interprété du langage. Alors pourquoi cette règle ?
Tout simplement pour conserver une frontière claire entre donnée et code
(l'ai-je déjà dit dans une autre réponse ?).
Je me demande vraiment si savez lire... Je cite l'article : « Unless
precautions are taken to validate the data first, the eval technique is
subject to security vulnerabilities if the data and the entire
JavaScript environment is not within the control of a single trusted
source. »
Vous avez une manière très particulière de lire les réponses que je vous
ai déjà faites et de résumer l'article que je vous citais. En gros, vous
ne retenez que ce qui semble aller dans le sens de ce que vous croyez et
vous oubliez tout le reste.
Comme on dit : on ne saurait faire boire un âne qui n'a pas soif.
> Javascript n'est rien d'autre que sa propre fonction eval
Et alors ?
Les fonctions de type 'eval' n'existent que dans les langages
interprétés (Ex: PHP, Perl, Python, Javascript, Lisp, etc.).
la plupart ne sont plus depuis longtemps interprétés mais plutôt
semi-compilés (voire même compilés au vol).
Et pourtant toutes les règles de bonnes pratiques de programmation
déconseille l'usage de ces fonctions 'eval'. Cette règle n'a donc rien à
voir avec la nature interprété du langage. Alors pourquoi cette règle ?
Tout simplement pour conserver une frontière claire entre donnée et code
(l'ai-je déjà dit dans une autre réponse ?).
Je me demande vraiment si savez lire... Je cite l'article : « Unless
precautions are taken to validate the data first, the eval technique is
subject to security vulnerabilities if the data and the entire
JavaScript environment is not within the control of a single trusted
source. »
Vous avez une manière très particulière de lire les réponses que je vous
ai déjà faites et de résumer l'article que je vous citais. En gros, vous
ne retenez que ce qui semble aller dans le sens de ce que vous croyez et
vous oubliez tout le reste.
Comme on dit : on ne saurait faire boire un âne qui n'a pas soif.
> Javascript n'est rien d'autre que sa propre fonction eval
Et alors ?
Les fonctions de type 'eval' n'existent que dans les langages
interprétés (Ex: PHP, Perl, Python, Javascript, Lisp, etc.).
la plupart ne sont plus depuis longtemps interprétés mais plutôt
semi-compilés (voire même compilés au vol).
Et pourtant toutes les règles de bonnes pratiques de programmation
déconseille l'usage de ces fonctions 'eval'. Cette règle n'a donc rien à
voir avec la nature interprété du langage. Alors pourquoi cette règle ?
Tout simplement pour conserver une frontière claire entre donnée et code
(l'ai-je déjà dit dans une autre réponse ?).
Je me demande vraiment si savez lire... Je cite l'article : « Unless
precautions are taken to validate the data first, the eval technique is
subject to security vulnerabilities if the data and the entire
JavaScript environment is not within the control of a single trusted
source. »
Vous avez une manière très particulière de lire les réponses que je vous
ai déjà faites et de résumer l'article que je vous citais. En gros, vous
ne retenez que ce qui semble aller dans le sens de ce que vous croyez et
vous oubliez tout le reste.
Comme on dit : on ne saurait faire boire un âne qui n'a pas soif.
> Javascript n'est rien d'autre que sa propre fonction eval
Et alors ?
Les fonctions de type 'eval' n'existent que dans les langages
interprétés (Ex: PHP, Perl, Python, Javascript, Lisp, etc.).
la plupart ne sont plus depuis longtemps interprétés mais plutôt
semi-compilés (voire même compilés au vol).
Et pourtant toutes les règles de bonnes pratiques de programmation
déconseille l'usage de ces fonctions 'eval'. Cette règle n'a donc rien à
voir avec la nature interprété du langage. Alors pourquoi cette règle ?
Tout simplement pour conserver une frontière claire entre donnée et code
(l'ai-je déjà dit dans une autre réponse ?).
Je me demande vraiment si savez lire... Je cite l'article : « Unless
precautions are taken to validate the data first, the eval technique is
subject to security vulnerabilities if the data and the entire
JavaScript environment is not within the control of a single trusted
source. »
Vous avez une manière très particulière de lire les réponses que je vous
ai déjà faites et de résumer l'article que je vous citais. En gros, vous
ne retenez que ce qui semble aller dans le sens de ce que vous croyez et
vous oubliez tout le reste.
Comme on dit : on ne saurait faire boire un âne qui n'a pas soif.
> Javascript n'est rien d'autre que sa propre fonction eval
Et alors ?
Les fonctions de type 'eval' n'existent que dans les langages
interprétés (Ex: PHP, Perl, Python, Javascript, Lisp, etc.).
la plupart ne sont plus depuis longtemps interprétés mais plutôt
semi-compilés (voire même compilés au vol).
Et pourtant toutes les règles de bonnes pratiques de programmation
déconseille l'usage de ces fonctions 'eval'. Cette règle n'a donc rien à
voir avec la nature interprété du langage. Alors pourquoi cette règle ?
Tout simplement pour conserver une frontière claire entre donnée et code
(l'ai-je déjà dit dans une autre réponse ?).
Je me demande vraiment si savez lire... Je cite l'article : « Unless
precautions are taken to validate the data first, the eval technique is
subject to security vulnerabilities if the data and the entire
JavaScript environment is not within the control of a single trusted
source. »
Vous avez une manière très particulière de lire les réponses que je vous
ai déjà faites et de résumer l'article que je vous citais. En gros, vous
ne retenez que ce qui semble aller dans le sens de ce que vous croyez et
vous oubliez tout le reste.
Comme on dit : on ne saurait faire boire un âne qui n'a pas soif.
> Javascript n'est rien d'autre que sa propre fonction eval
Et alors ?
Les fonctions de type 'eval' n'existent que dans les langages
interprétés (Ex: PHP, Perl, Python, Javascript, Lisp, etc.).
la plupart ne sont plus depuis longtemps interprétés mais plutôt
semi-compilés (voire même compilés au vol).
Et pourtant toutes les règles de bonnes pratiques de programmation
déconseille l'usage de ces fonctions 'eval'. Cette règle n'a donc rien à
voir avec la nature interprété du langage. Alors pourquoi cette règle ?
Tout simplement pour conserver une frontière claire entre donnée et code
(l'ai-je déjà dit dans une autre réponse ?).
Je me demande vraiment si savez lire... Je cite l'article : « Unless
precautions are taken to validate the data first, the eval technique is
subject to security vulnerabilities if the data and the entire
JavaScript environment is not within the control of a single trusted
source. »
Vous avez une manière très particulière de lire les réponses que je vous
ai déjà faites et de résumer l'article que je vous citais. En gros, vous
ne retenez que ce qui semble aller dans le sens de ce que vous croyez et
vous oubliez tout le reste.
Comme on dit : on ne saurait faire boire un âne qui n'a pas soif.
donc il faut être certain de tout savoir avant de se lancer à écrire
quelque chose ?
la seule différence entre la version switch et la version eval
c'est l'existence de la fonction
le cross-site scripting n'utilise pas que du javascript
il renvoie des donnés de forme à des script php
donc il faut être certain de tout savoir avant de se lancer à écrire
quelque chose ?
la seule différence entre la version switch et la version eval
c'est l'existence de la fonction
le cross-site scripting n'utilise pas que du javascript
il renvoie des donnés de forme à des script php
donc il faut être certain de tout savoir avant de se lancer à écrire
quelque chose ?
la seule différence entre la version switch et la version eval
c'est l'existence de la fonction
le cross-site scripting n'utilise pas que du javascript
il renvoie des donnés de forme à des script php
mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
<script>
texte
</script>
que croyez vous que fait l'interprète javascript ?
tout simplement un eval("texte")
que croyez vous que fait l'interprète javascript ?
il charge le texte du fichier adresse et fait un eval(texte)
que croyez vous que fait l'interprète javascript sur un
onClick="texte"; ?
eval(texte)
je ne fais que reprendre votre affirmation
et elle est fausse , javascript est interprété et donc ne change pas le
texte en code , il interprète le texte ( un peu comme la version switch
dont on parlait )
il y a un compilateur js mais ça m'étonnerait qu'il soit natif sur les
navigateurs , et comme tout compilateur il génère du code machine ,
mieux vaut se méfier !
je résume : javascript interprète du texte et il faut donc faire
attention à son encodage
le risque d'erreur dont parle ce site concerne la confusion entre des
écritures de chaînes dans divers encodages
les erreurs générées sont des erreurs Javascript et n'ont rien à voir
avec la sécurité
mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
<script>
texte
</script>
que croyez vous que fait l'interprète javascript ?
tout simplement un eval("texte")
que croyez vous que fait l'interprète javascript ?
il charge le texte du fichier adresse et fait un eval(texte)
que croyez vous que fait l'interprète javascript sur un
onClick="texte"; ?
eval(texte)
je ne fais que reprendre votre affirmation
et elle est fausse , javascript est interprété et donc ne change pas le
texte en code , il interprète le texte ( un peu comme la version switch
dont on parlait )
il y a un compilateur js mais ça m'étonnerait qu'il soit natif sur les
navigateurs , et comme tout compilateur il génère du code machine ,
mieux vaut se méfier !
je résume : javascript interprète du texte et il faut donc faire
attention à son encodage
le risque d'erreur dont parle ce site concerne la confusion entre des
écritures de chaînes dans divers encodages
les erreurs générées sont des erreurs Javascript et n'ont rien à voir
avec la sécurité
mais quand vous écrivez ( ne chipotez pas sur la syntaxe svp )
<script>
texte
</script>
que croyez vous que fait l'interprète javascript ?
tout simplement un eval("texte")
que croyez vous que fait l'interprète javascript ?
il charge le texte du fichier adresse et fait un eval(texte)
que croyez vous que fait l'interprète javascript sur un
onClick="texte"; ?
eval(texte)
je ne fais que reprendre votre affirmation
et elle est fausse , javascript est interprété et donc ne change pas le
texte en code , il interprète le texte ( un peu comme la version switch
dont on parlait )
il y a un compilateur js mais ça m'étonnerait qu'il soit natif sur les
navigateurs , et comme tout compilateur il génère du code machine ,
mieux vaut se méfier !
je résume : javascript interprète du texte et il faut donc faire
attention à son encodage
le risque d'erreur dont parle ce site concerne la confusion entre des
écritures de chaînes dans divers encodages
les erreurs générées sont des erreurs Javascript et n'ont rien à voir
avec la sécurité