BBCode

Le principal avantage du BBCode est que sa syntaxe est souvent plus concise et explicite que le HTML. La mise en forme est ainsi plus conviviale, même pour les utilisateurs non familiers avec le concept de balisage. Par exemple, comparer ces deux syntaxes pour mettre un texte en rouge :

  En BBCode : [rouge]Texte[/rouge]
  En HTML :   <span style="color:red">Texte</span>

Le BBCode permet également au webmaster de restreindre le nombre des mises en forme à disposition de ses utilisateurs. Ceci permet, d'une part, de conserver une cohérence visuelle (par exemple, la taille, la couleur et les marges des titres seront identiques) et, d'autre part, d'empêcher l'emploi de mises en forme jugées peu esthétiques (surlignement, texte clignotant, etc.).

L'absence de normalisation des balises BBCode oblige l'utilisateur à s'adapter en fonction du forum ou site sur lequel il écrit. Certaines balises fonctionneront sur un site mais pas sur un autre, d'autres porteront un autre nom, ou porteront le même nom mais avec une syntaxe différente, etc. Les conflits entre noms de balises peuvent être problématiques. Par exemple, la balise [s]...[/s] signifiera « rayer le texte » sur un forum anglophone (strike) mais « souligner » sur un forum francophone, ce qui change le sens de la mise en forme.

Le BBCode pose un problème plus global d'interopérabilité. Si un webmaster change le système de gestion de contenu de son site, certaines balises utilisées dans les anciens messages risquent de ne plus fonctionner.

Contrairement à une idée répandue, le BBCode n'offre que peu de protection contre les injections de code malveillant. Il est vrai que le principe d'établir une liste blanche des balises autorisées empêche l'usage de balises HTML dangereuses telles que la balise <script>, qui permettrait d'exécuter du code Javascript, ou <frame>, qui inclurait une page d'un site tiers dans la page d'origine. Cependant, il ne suffit pas de maîtriser les noms des balises, il faut également contrôler la valeur de leurs attributs. Par exemple, ce BBCode destiné à insérer une image[1] :

  [img]http://sitelambda.com/image.jpg[/img]

devient normalement, après conversion en HTML :

  <img src="http://sitelambda.com/image.jpg" />

On peut tenter d'y injecter du code malveillant en fermant prématurément le guillemet (....jpg") et en ouvrant une instruction Javascript non prévue (onerror="...) :

 [img]http://sitelambda.com/image.jpg" onerror="alert{location}[/img]

Si le convertisseur se contente de récupérer le contenu de la balise sans le contrôler, il produira ce code HTML potentiellement dangereux :

  <img src="http://sitelambda.com/image.jpg" onerror="alert{location}" />

On voit ici que du code nuisible a pu être injecté sans avoir besoin de recourir à une balise non autorisée. En outre, la faille de sécurité est ouverte par une balise qui semble à première vue inoffensive (insertion d'une image). Cette faille provient de l'absence de filtrage des données. Dans cet exemple, le convertisseur aurait dû s'assurer que la balise [img] ne contient qu'une url. Le niveau de sécurité dépendra ensuite du niveau de tolérance du filtre : a minima, il devrait contrôler que l'adresse commence par « http:// » et ne contient pas d'espace ; la sécurité peut être renforcée en vérifiant, par exemple, que l'extension du fichier ciblé correspond bien à une image (JPEG, PNG, GIF...).

Seule la mise en place de procédures de filtrage du texte envoyé assure réellement la sécurité. L'existence de ce filtrage étant indépendante du format des données de départ, un texte formaté en BBCode peut tout à fait contenir du code malveillant et, inversement, l'utilisateur peut être autorisé à saisir des balises HTML sans que cela crée pour autant de faille de sécurité.

Dans le contexte du Web 2.0, de nouveaux langages de balisage simplifié ont émergé. On peut citer les XBBCodes, qui valorisent le contenu de façon sémantique, et les Wikicodes, qui autorisent des mises en forme très élaborées.

Toutefois, tous les langages de balisage simplifié sont concurrencés par les éditeurs WYSIWYG, qui permettent à l'utilisateur de voir la mise en forme réelle de son texte sans aucune balise apparente, à la manière d'un logiciel de traitement de texte. Un balisage est toujours présent mais, étant géré par un programme et non plus par l'utilisateur, il n'est plus nécessaire de le simplifier au moyen d'un BBCode.

Le principe même de mise en forme des messages a tendance à reculer depuis les années 2010. Notamment, Facebook, site de réseautage social le plus fréquenté revendiquant 2 milliards de comptes actifs en 2017[2], n'affichait jusqu'en 2019 aucune option de mise en forme des messages[3]. On peut citer comme raisons la tendance générale à la simplification des interfaces, la préférence pour la rapidité des réactions et des échanges et le fait que la navigation sur un support mobile et tactile (smartphone, tablette) rend la mise en forme malaisée.