La bibliographie originelle est
http://www.javasoft.com/sfaq/index.html
On peut lire aussi un résumé en français à : http://cedric.cnam.fr/~farinone/AFCET/7.html et .../8.html

La sécurité dans Java est implantée à différent niveaux :

- Tous les types primitifs ont même taille, pas d'arithmétique sur les pointeurs (et donc pas de parcours de la mémoire).

- Les références aux méthodes et aux instances ne peuvent être manipulés que par des noms symboliques.

- Le langage est fortement typé et intransigeant sur les conversions illégales (entier converti en objets ou vice versa interdit).

- La libération de la mémoire n'est pas à la charge du programmeur mais est géré par le ramasse-miettes.

Le code Java a pu éventuellement être généré par compilateur hostile et les browsers n'ont pas de moyen pour le savoir. Aussi d'autres barrières de sécurité ont été mises après la compilation.

L'interpréteur ne peut exécuter que du code déjà compilé et pas de fichier source.

Les classes sont rangées dans des zones propres à leur origine => les classes locales et fondamentales sont d'abord utilisées.

Le byte code des classes suivent un format décrit par le langage. Chaque champ de donnée et méthode sont accompagnés de leur signature.

est une partie intégrée dans l'interpréteur. Il fonctionne en 4 passes. La passe la plus importante est : le byte code verifier

Le byte code de chaque méthode est vérifié. Ce code est découpé en suite d'instructions. Cette passe vérifie alors que tout branchement débute au début d'une instruction (ni au milieu, ni avant ou après le code).

Chaque exécution est d'abord "émulé" avant d'être effectuée :

- si une instruction a besoin de valeurs dans la pile, cette passe vérifie que ces valeurs (de bons type) y sont

- idem pour les registres

- si l'instruction doit empiler, cette passe vérifie que la pile a assez de place.

Toute application Java implante sa propre sécurité à l'aide d'un objet chargé une et une seule fois au début du lancement de l'application : un objet d'une sous classe de la classe SecurityManager.

C'est le cas des browsers.

Cet objet est unique à l'intérieur d'une application Java, ne peut pas être remplacé. Les applets ne peuvent pas le référencer.

De ce fait la plupart des browsers (Netscape Navigator, Internet Explorer, ...) implante une politique sécurisé très draconienne ( le browser le plus souple est hotjava).

En règle générale on peut retenir (même si en fait c'est beaucoup plus "fin" qu'a priori les applets Java (du à l'implantation de la politique de sécurité des browsers) ne peuvent pas :

- lire ou écrire dans des fichiers locaux

- détruire des fichiers locaux (soit en se servant de File.delete() soit en lançant une commande système rm ou del)

- renommer des fichiers locaux (soit en se servant de File.renameTo() soit en lançant une commande système mv ou rename)

- créer un répertoire sur le système local (soit en se servant de File.mkdir() soit ou File.mkdirs() en lançant une commande système mkdir)

- lister le contenu d'un répertoire local.

- vérifier l'existence, la taille, le type, la date de dernière modification d'un fichier local

- charger des librairies ou des méthodes natives.

- ...