Le SPA est-il faillible? (avec notes)

Le SPA est-il faillible?
La plupart des organisations faisant du développement web ont déjà ou veulent
introduire cette "nouvelle" technique qu’est le SPA…
Toutefois est-ce fait de façon sécuritaire?
Une brève exploration du passé nous montrera ce que nous avons appris et
probablement oublié avec cette nouvelle guerre du « Front-End ».
Par la suite, nous allons voir ce qu’est une SPA, les changements que ça apporte aux
étapes de développement ainsi que les avantages et inconvénients pour les
développeurs et les utilisateurs.
Le tout sera accompagné d’exemples vous montrant que les directions initialement
prises doivent changer.
Finalement, nous verrons ce qu’il faut retenir du passé pour ne pas répéter les
mêmes erreurs.
1

Au sujet du gars …
Franck Desert
Analyste en sécurité,
Architecte organique senior
2

Les origines du terme application à une page ne sont pas claires, bien que le concept ait été
discuté au moins dès 2003.
Stuart (stunix) Morris a écrit le site Web autonome sur slashdotslash.com avec les
mêmes objectifs et fonctions en avril 2002 et, plus tard la même année, Lucas Birdeau, Kevin
Hakman, Michael Peachey et Evan Yeh ont décrit une application de page unique.
Brevet US 8 136 109.
Le terme a été introduit par Steve Yen en 2005.
MVC 1980
MVVM
1991
Gang of Four
SOLID, KISS, DRY, YAGNI
JavaScript peut être utilisé dans un navigateur Web pour afficher l'interface
utilisateur, exécuter la logique de l'application et communiquer avec un serveur Web.
Des bibliothèques Open Source matures sont disponibles pour prendre en charge la
création d'un SPA, réduisant ainsi la quantité de code JavaScript que le développeur
doit écrire.
Une application web monopage (en anglais single-page application ou SPA) est une
application web accessible via une page web unique. Le but est d'éviter le
chargement d'une nouvelle page à chaque action demandée, et de fluidifier ainsi
l'expérience utilisateur. Deux méthodes existent pour ce faire : l'ensemble des
éléments de l'application est chargé (contenu, images, CSS et JavaScript) dans un
unique fichier HTML, soitles ressources nécessaires sont récupérées et affichées
dynamiquement en fonction des actions de l'utilisateur.
L'enregistrement en local de la page définissant une application web monopage et la
possibilité de continuer à l'exécuter en local est l'une des propriétés importantes des
applications web monopage qui les distingue des applications web standards qui
3

reposent sur l'existence d'un serveur HTTP avec lequel elles échangent données,
continuations applicatives et interfaces.
Quand les applications web monopages gèrent des données et permettent de les
modifier, pour conserver ces données modifiées, il est nécessaire que ces
applications modifient leur code, c'est-à-dire : elles doivent être capable de se
modifier pour que la sauvegarde locale de l'état modifié de l'application (dont les
données) soit persistant.
TiddlyWiki est un exemple d'application web monopage.
YAGNI (You Aren't Gonna Need It)
DRY (Don't Repeat Yourself)
KISS (Keep It Simple, Silly or Keep It Simple & Stupid)
https://siderite.blogspot.com/2017/02/solid-principles-plus-dry-yagni-kiss-final.html
https://thefullstack.xyz/dry-yagni-kiss-tdd-soc-bdfu
https://softwareengineering.stackexchange.com/questions/73065/what-are-dry-kiss-
solid-etc-classified-as
3

The term user experience was brought to wider knowledge by Donald Norman in the
mid-1990s.[4] He never intended the term "user experience" to be applied only to the
affective aspects of usage. A review of his earlier work [5] suggests that the term "user
experience" was used to signal a shift to include affective factors, along with the pre-
requisite behavioral concerns, which had been traditionally considered in the field.
Many usability practitioners continue to research and attend to affective factors
associated with end-users, and have been doing so for years, long before the term
"user experience" was introduced in the mid-1990s.[citation needed] In an interview in
2007, Norman discusses the widespread use of the term "user experience" and its
imprecise meaning as a consequence thereof.[6]
Several developments affected the rise of interest in the user experience
Recent advances in mobile, ubiquitous, social, and tangible computing technologies
have moved human-computer interaction into practically all areas of human activity.
This has led to a shift away from usability engineering to a much richer scope of user
experience, where users' feelings, motivations, and values are given as much, if not
more, attention than efficiency, effectiveness and basic subjective satisfaction (i.e.
the three traditional usability metrics[7]).[8]
In website design, it was important to combine the interests of different stakeholders:
marketing, branding, visual design, and usability. Marketing and branding people
4

needed to enter the interactive world where usability was important. Usability people
needed to take marketing, branding, and aesthetic needs into account when
designing websites. User experience provided a platform to cover the interests of all
stakeholders: making web sites easy to use, valuable, and effective for visitors. This is
why several early user experience publications focus on website user
experience.[9][10][11][12]
User experience design
https://en.wikipedia.org/wiki/User_experience_design
User experience design (UX, UXD, UED or XD) is the process of enhancing user
satisfaction with a product by improving the usability, accessibility, and pleasure
provided in the interaction with the product.[1] User experience design encompasses
traditional human–computer interaction (HCI) design, and extends it by addressing all
aspects of a product or service as perceived by users.[2]
UX and VR
https://www.renacen.com/blog/5-keys-applying-virtual-reality-user-experience/
4

Responsive web design (RWD) is an approach to web design that makes web pages
render well on a variety of devices and window or screen sizes. Recent work also
considers the viewer proximity as part of the viewing context as an extension for
RWD.[1] Content, design and performance are necessary across all devices to ensure
usability and satisfaction.[2][3][4][5]
A site designed with RWD[2][6] adapts the layout to the viewing environment by using
fluid, proportion-based grids,[7][8] flexible images,[9][10][11] and CSS3 media
queries,[4][12][13] an extension of the @media rule, in the following ways:[14]
The fluid grid concept calls for page element sizing to be in relative units like
percentages, rather than absolute units like pixels or points.[8]
Flexible images are also sized in relative units, so as to prevent them from displaying
outside their containing element.[9]
Media queries allow the page to use different CSS style rules based on characteristics
of the device the site is being displayed on, most commonly the width of the browser.
Responsive web design has become more important as the amount of mobile traffic
now accounts for more than half of total internet traffic.[15] Therefore, Google
5

announced Mobilegeddon in 2015, and started to boost the ratings of sites that are
mobile friendly if the search was made from a mobile device.[16] Responsive web
design is an example of user interface plasticity.[17]
Adaptive web design (AWD) promotes the creation of multiple versions of a web
page to better fit the user's device, as opposed to a single version that other web
design techniques use.
Adaptive web design encompasses a range of other strategies that can be combined
with responsive web design.[1]
https://en.wikipedia.org/wiki/Adaptive_web_design
Techniques
Adaptive web design uses multiple page layouts for a single web page and sometimes
progressive enhancement (PE). The adaptive model is a "mobile separate" layout, in
contrast to "mobile first", unobtrusive JavaScript, and progressive enhancement of
RWD.[citation needed]
"Mobile separate", unobtrusive JavaScript, and progressive enhancement
"Mobile separate" is the same concept as "mobile first", except the design layout of
AWD is to have a separate base mobile layout versus the single design layout of RWD.
Browsers of basic mobile phones do not understand JavaScript or media queries, so a
recommended practice is to create a basic mobile layout and use unobtrusive
JavaScript and progressive enhancement for smart phones, rather than rely on
graceful degradation to make a complex, image-heavy site work.[3][4][5][6]
La dégradation élégante dans le domaine de la conception web correspond au début
des années 2000 découlant de l'adoption massive à deux nouveaux concepts tels que
la séparation du fond (sémantique XHTML) et de la forme (CSS), l'adoption des
standards du W3C grâce à l'émergence de nouveaux navigateurs sur le marché
(Firefox, Opera). Cette idée de régression était soutenue par l'amélioration rapide et
continue des technologies du moment, les développeurs visant d'abord les
navigateurs les plus récents et considérant ensuite les anciennes versions.
Amélioration progressive vs dégradation élégante
Ces deux méthodes ont un même but, rendre le contenu accessible au plus grand
nombre. Ce qui les oppose est leur approche du problème :
5

dégradation élégante : l'approche est dite top-down, on développe d'abord pour une
configuration précise, puis on s'efforce d'étendre le nombre de configurations
capables de rendre le contenu correctement ;
l'amélioration progressive : l'approche est dite bottom-up ou par couche ; les couches
sont développées de la plus basique et la plus universelle à la plus spécifique, comme
suit :
couche sémantique (XHTML, XML) :
contenu accessible pour tous (tout est balisé) ;
fonctionnalité accessible pour tous (tout est « cliquable ») ;
couche visuelle (CSS) :
la mise en forme est gérée par des feuilles de style externes ;
couche événementielle (JavaScript, AJAX) :
les comportements évolués sont non-obstrusifs et gérés par des
fichiers externes
respect des préférences utilisateur.
5

Thin server architecture
stateful server architecture
stateless server architecture
Architecture serveur
Thin server architecture
Un SPA déplace la logique du serveur vers le client, le rôle du serveur Web évoluant
vers une API de données ou un service Web pur. Dans certains milieux, ce
changement d’architecture a été appelé «architecture de serveur mince» pour
souligner que la complexité a été déplacée du serveur vers le client, avec l’argument
que cela réduit la complexité globale du système.
stateful server architecture
Le serveur conserve l'état nécessaire en mémoire de l'état du client de la page. De
cette façon, lorsqu'une requête frappe le serveur (généralement des actions
utilisateur), le serveur envoie le code HTML et / ou JavaScript approprié avec les
modifications concrètes pour amener le client au nouvel état souhaité (en ajoutant /
supprimant / mettant à jour une partie du fichier) client le DOM. Dans le même
temps, l'état du serveur est mis à jour. La plupart de la logique est exécutée sur le
serveur et HTML est généralement également rendu sur le serveur.
À certains égards, le serveur simule un navigateur Web, reçoit des événements et
effectue des modifications delta de l’état du serveur qui sont automatiquement
6

propagées au client.
Cette approche nécessite davantage de mémoire serveur et de traitement serveur,
mais l'avantage est un modèle de développement simplifié car
a) l'application est généralement entièrement codée sur le serveur et,
b) les données et l'état de l'interface utilisateur sont partagés dans le même espace
mémoire. besoin de ponts de communication client / serveur personnalisés.
stateless server architecture
Ceci est une variante de l'approche serveur avec état. La page client envoie des
données représentant son état actuel au serveur, généralement par le biais de
requêtes Ajax.
En utilisant ces données, le serveur est capable de reconstruire l’état du client de la
partie de la page à modifier et de générer les données ou le code nécessaires
(par exemple, JSON ou JavaScript), qui sont renvoyés au client à un nouvel état, en
modifiant généralement l’arbre DOM de la page en fonction de l’action client qui a
motivé la requête.
Cette approche nécessite l'envoi de davantage de données au serveur et peut
nécessiter davantage de ressources de calcul par requête pour reconstruire
partiellement ou totalement l'état de la page du client sur le serveur. Dans le même
temps, cette approche est plus facilement évolutive car aucune donnée de page par
client n'est conservée sur le serveur et, par conséquent, les requêtes Ajax peuvent
être distribuées vers différents nœuds de serveur sans partage de données de session
ni affinité de serveur.
6

Cycle de vie de la page
Un SPA est entièrement chargé dans le chargement de page initial, puis les régions de
page sont remplacées ou mises à jour avec de nouveaux fragments de page chargés à
partir du serveur à la demande. Pour éviter un téléchargement excessif des
fonctionnalités inutilisées, un SPA télécharge souvent progressivement davantage de
fonctionnalités à mesure qu'elles deviennent nécessaires, que ce soit de petits
fragments de la page ou des modules d'écran complets.
De cette manière, il existe une analogie entre les "états" dans un SPA et les "pages"
sur un site Web traditionnel.
Comme la "navigation par état" dans la même page est analogue à la navigation par
page, en théorie, tout site Web basé sur une page pourrait être converti en une seule
page en remplaçant uniquement les parties modifiées par des pages consécutives
dans une autre page.
L'approche SPA sur le Web est similaire à la technique de présentation SDI (Single
Document Interface) utilisée couramment dans les applications de bureau natives
7

Challenges SPA modèle
Bibliothèques JavaScript côté client traitant de divers problèmes.
Structures Web côté serveur spécialisées dans le modèle SPA
L'évolution des navigateurs et la spécification HTML5 conçue pour le modèle SPA
Search engine optimization (SEO)
Client/Serveur code partitionné
Historique du navigateur
Ajout de chargements de page à un SPA
Vitesse de charge initiale
Accélérer le chargement de la page
Ceci est un scénario de compromis "payez-moi maintenant ou payez-moi plus tard".
Challenges with the SPA model
Because the SPA is an evolution away from the stateless page-redraw model that
browsers were originally designed for, some new challenges have emerged.
Each of these problems has an effective solution with:
Client-side JavaScript libraries addressing various issues.
Server-side web frameworks that specialize in the SPA model
The evolution of browsers and the HTML5 specification designed for the SPA model
Search engine optimization (SEO)
En raison de l'absence d'exécution de JavaScript sur les moteurs de
recherche de certains moteurs de recherche Web populaires, SEO (Search engine
optimization) a toujours posé problème aux sites Web publics souhaitant adopter le
modèle SPA
8

En raison de l'absence d'exécution de JavaScript sur les moteurs de
recherche de certains moteurs de recherche Web populaires, [20] SEO (Search engine
optimization) a toujours posé problème aux sites Web publics souhaitant adopter le
modèle SPA [21].
Entre 2009 et 2015, Google Webmaster Central a proposé puis
recommandé un "schéma d'analyse AJAX" [22] [23] utilisant un point d'exclamation
initial dans les identificateurs de fragment pour les pages AJAX avec état (#!). Un
comportement spécial doit être implémenté par le site SPA pour permettre
l'extraction des métadonnées pertinentes par le robot du moteur de recherche. Pour
les moteurs de recherche qui ne prennent pas en charge ce schéma de hachage
d'URL, les URL hachées du SPA restent invisibles. Ces URI "hash-bang" ont été
considérés comme problématiques par un certain nombre d'auteurs, y compris Jeni
Tennison au W3C, car ils rendent les pages inaccessibles à ceux qui n'ont pas
JavaScript activé dans leur navigateur. Ils rompent également les en-têtes de
référence HTTP, car les navigateurs ne sont pas autorisés à envoyer l'identificateur de
fragment dans l'en-tête Referer. [24] En 2015, Google a déprécié sa proposition
d'analyse de hash-bang AJAX. [25]
Les applications peuvent également rendre la première page chargée
sur le serveur et les mises à jour de pages ultérieures sur le client. Cela est
traditionnellement difficile, car le code de rendu peut devoir être écrit dans un autre
langage ou une autre structure sur le serveur et dans le client. L'utilisation de
modèles sans logique, la compilation croisée d'une langue à une autre ou l'utilisation
du même langage sur le serveur et le client peuvent aider à augmenter la quantité de
code pouvant être partagée.
Comme la compatibilité SEO n'est pas triviale dans les SPA, il convient
de noter que les SPA ne sont généralement pas utilisés dans un contexte où
l'indexation par moteur de recherche est une exigence ou souhaitable. Les cas
d'utilisation incluent des applications qui recouvrent des données privées cachées
derrière un système d'authentification. Dans les cas où ces applications sont des
produits grand public, un modèle classique de «redessinage» est souvent utilisé pour
la page de destination et le site marketing des applications, qui fournit suffisamment
de métadonnées pour que l'application apparaisse comme une requête dans un
moteur de recherche. Les blogs, les forums de support et autres artefacts
traditionnels de redécalage de pages sont souvent placés autour du SPA, ce qui peut
générer des termes pertinents pour les moteurs de recherche.
Une autre approche utilisée par les frameworks Web centrés sur le
serveur, comme ItsNat basé sur Java, consiste à rendre tout hypertexte sur le serveur
en utilisant le même langage et la même technologie de template. Dans cette
8

approche, le serveur connaît avec précision l’état du DOM sur le client, toute mise à
jour de petite ou grande page requise est générée sur le serveur et transportée par
Ajax, le code JavaScript exact pour amener la page client au nouvel état . Les
développeurs peuvent décider quels états de page doivent être explorés par les
spiders pour le référencement et être en mesure de générer l'état requis au moment
du chargement en générant du code HTML au lieu de JavaScript. Dans le cas du
framework ItsNat, cela est automatique car ItsNat conserve l’arborescence DOM du
client sur le serveur en tant qu’arborescence DOM W3C Java; le rendu de cet arbre
DOM sur le serveur génère du code HTML simple au moment du chargement et des
actions DOM JavaScript pour les requêtes Ajax. Cette dualité est très importante pour
le référencement car les développeurs peuvent construire avec le même code Java et
le même modèle basé sur HTML que l’état DOM souhaité sur le serveur; Au moment
du chargement de la page, le code HTML classique est généré par ItsNat, ce qui rend
cet état compatible avec le référencement. A partir de la version 1.3, [26] ItsNat
fournit un nouveau mode sans état, et le DOM client n'est pas conservé sur le serveur
car, avec le client en mode sans état, l'état du DOM est partiellement ou totalement
reconstruit lors du traitement de toute requête Ajax basée sur données requises
envoyées par le client informant le serveur de l'état DOM actuel; Le mode sans état
peut également être compatible avec le SEO car la compatibilité SEO se produit au
moment du chargement de la page initiale, sans être affecté par les modes avec ou
sans état.
Il existe plusieurs solutions pour donner l'impression que le site Web
est explorable. Les deux impliquent la création de pages HTML distinctes qui reflètent
le contenu du SPA. Le serveur peut créer une version HTML du site et la distribuer aux
robots d'exploration, ou utiliser un navigateur sans tête tel que PhantomJS pour
exécuter l'application JavaScript et générer le code HTML résultant.
Les deux nécessitent beaucoup d'efforts et peuvent finir par causer
des problèmes de maintenance pour les grands sites complexes. Il existe également
des pièges potentiels en matière de référencement. Si le code HTML généré par le
serveur est jugé trop différent du contenu du SPA, le site sera pénalisé. L'exécution de
PhantomJS pour générer le HTML peut ralentir la vitesse de réponse des pages, ce qui
est un facteur pour lequel les moteurs de recherche - en particulier Google -
abaissent le classement. [27]
Client/Server code partitioning
Une manière d'augmenter la quantité de code pouvant être partagée
entre les serveurs et les clients consiste à utiliser un langage de modèle sans logique
comme Moustache ou Handlebars. De tels modèles peuvent être rendus à partir de
8

différents langages hôtes, tels que Ruby sur le serveur et JavaScript dans le client.
Cependant, le simple partage de modèles nécessite généralement la duplication de la
logique métier utilisée pour choisir les modèles corrects et les remplir avec des
données. Le rendu à partir de modèles peut avoir des effets négatifs sur les
performances lors de la mise à jour d'une petite partie seulement de la page, par
exemple la valeur d'une entrée de texte dans un grand modèle. Remplacer un modèle
entier peut également perturber la sélection d'un utilisateur ou la position du
curseur, alors que la mise à jour de la seule valeur modifiée peut ne pas l'être. Pour
éviter ces problèmes, les applications peuvent utiliser des liaisons de données
d'interface utilisateur ou des manipulations granulaires pour mettre à jour
uniquement les parties appropriées de la page au lieu de restituer des modèles
entiers.
Historique du navigateur
Avec un SPA étant, par définition, "une seule page", le modèle rompt
la conception du navigateur pour la navigation dans l'historique des pages à l'aide des
boutons Avant / Arrière. Cela pose un problème de convivialité lorsqu'un utilisateur
appuie sur le bouton Précédent, en attendant l'état d'écran précédent dans le SPA,
mais à la place, la page unique de l'application se décharge et la page précédente de
l'historique du navigateur est présentée.
La solution traditionnelle pour les SPA était de changer l'identifiant du
fragment de hachage de l'URL du navigateur en fonction de l'état de l'écran actuel.
Cela peut être réalisé avec JavaScript et permet de créer des événements d’historique
d’URL dans le navigateur. Tant que le SPA est capable de ressusciter le même état
d'écran à partir des informations contenues dans le hachage d'URL, le comportement
attendu du bouton arrière est conservé.
Le hachage peut également être utilisé pour les applications à une
seule page. Au lieu de l'utiliser pour naviguer jusqu'à un point d'une page, vous
utilisez le hachage comme moyen de naviguer d'une page à l'autre. L'avantage de ceci
est qu'il ne nécessite pas d'actualisation de la page.
Il existe également une méthode appelée hashbanging utilisée pour
les applications à une seule page et utilisée pour aider les applications ajax à être plus
indexables.
Il y a quelques bons articles sur le sujet
8

https://github.com/browserstate/history.js/wiki/Intelligent-State-Handling
http://danwebb.net/2011/5/28/it-is-about-the-hashbangs
https://developers.google.com/webmasters/ajax-crawling/
Pour répondre à ce problème, la spécification HTML5 a introduit
pushState et replaceState, fournissant un accès par programmation à l’URL et à
l’historique du navigateur.
Analytique
Les outils d'analyse tels que Google Analytics s'appuient fortement sur
le chargement de nouvelles pages entières dans le navigateur, initié par un nouveau
chargement de page. Les SPA ne fonctionnent pas de cette façon.
Après le chargement de la première page, toutes les modifications de
page et de contenu ultérieures sont traitées en interne par l'application, qui doit
simplement appeler une fonction pour mettre à jour le package d'analyse. Faute
d'appeler cette fonction, le navigateur ne déclenche jamais un nouveau chargement
de la page, rien ne s'ajoute à l'historique du navigateur et le module d'analyse n'a
aucune idée de qui fait quoi sur le site.
Ajout de chargements de page à un SPA
Il est possible d'ajouter des événements de chargement de page à un
SPA à l'aide de l'API HTML5 History; Cela aidera à intégrer les analyses. La difficulté
réside dans la gestion de ce problème et dans la garantie d'un suivi précis de tous les
éléments, ce qui implique de rechercher les rapports manquants et les doubles
entrées. Certains frameworks fournissent des intégrations d'analyse open source
s'adressant à la plupart des principaux fournisseurs d'analyses. Les développeurs
peuvent les intégrer dans l'application et s'assurer que tout fonctionne correctement,
mais il n'est pas nécessaire de tout faire à partir de zéro.
Vitesse de charge initiale
Les applications à une seule page sont moins chargées que les
applications basées sur un serveur. Cela est dû au fait que le premier chargement doit
mettre à jour l’infrastructure et le code de l’application avant de rendre la vue requise
au format HTML dans le navigateur. Une application basée sur un serveur doit
simplement transférer le code HTML requis vers le navigateur, réduisant ainsi la
latence et le temps de téléchargement.
8

Accélérer le chargement de la page
Il existe des moyens d'accélérer le chargement initial d'un SPA, par
exemple une approche lourde de la mise en cache et des modules de chargement
différé en cas de besoin. Mais il n'est pas possible de s'éloigner du fait qu'il a besoin
de télécharger la structure, au moins une partie du code de l'application, et va
probablement toucher une API pour les données avant d'afficher quelque chose dans
le navigateur. Ceci est un scénario de compromis "payez-moi maintenant ou payez-
moi plus tard". La question de la performance et des temps d’attente reste une
décision que le développeur doit prendre.
8

En résumé …
Avant les SPA, il y avait quoi?
• Il s’agissait de MPA (multipage application)
• Un client demandait l’accès à une page web
• Le serveur lui envoyait le contenu de la page
• Les informations nécessaires et disponibles à
l’utilisateur étaient envoyées dans le contenu de la page
• Très peu de réutilisation de code
• MVC (Model – View – Controller)
• Possibilité d’utiliser des Frameworks
• Symfony
• ASP.Net
• Etc.
9
https://arxiv.org/abs/cs/0610094
9

En résumé …
Avec SPA, c’est quoi?
• SPA pour Single Page Application
• Une application web qui réécrit dynamiquement la page plutôt que de charger une
nouvelle page à chaque fois. Tout le code (HTML, JavaScript et CSS) est reçu au
premier chargement.
• Le visuel est téléchargé qu’une seule fois
• Attention, on ne parle pas de toute l’application, seulement du visuel
• L’application est essentiellement faite en JavaScript côté client
• Plusieurs Framework aident au développement et utilisent le principe
du SPA
• Angular, React, Vue.js, etc.
• Utilisation d’une API pour la récupération des données Backend
• Code divisé en composants etou modules
• Aide à la réutilisation du code
10
Une application web monopage (en anglais single-page application ou SPA) est une
application web accessible via une page web unique. Le but est d'éviter le
chargement d'une nouvelle page à chaque action demandée, et de fluidifier ainsi
l'expérience utilisateur. Deux méthodes existent pour ce faire : l'ensemble des
éléments de l'application est chargé (contenu, images, CSS et JavaScript) dans un
unique fichier HTML, soit les ressources nécessaires sont récupérées et affichées
dynamiquement en fonction des actions de l'utilisateur. Le terme a été introduit par
Steve Yen en 2005.
L'enregistrement en local de la page définissant une application web monopage et la
possibilité de continuer à l'exécuter en local est l'une des propriétés importantes des
applications web monopage qui les distingue des applications web standards qui
reposent sur l'existence d'un serveur HTTP avec lequel elles échangent données,
continuations applicatives et interfaces.
Quand les applications web monopages gèrent des données et permettent de les
modifier, pour conserver ces données modifiées, il est nécessaire que ces
applications modifient leur code, c'est-à-dire : elles doivent être capable de se
modifier pour que la sauvegarde locale de l'état modifié de l'application (dont les
données) soit persistant.
10

TiddlyWiki est un exemple d'application web monopage.
Technical approaches
There are various techniques available that enable the browser to retain a single page
even when the application requires server communication.
JavaScript frameworks
Web browser JavaScript frameworks, such as AngularJS, Ember.js, Knockout.js,
Meteor.js, ExtJS, Vue.js and React have adopted SPA principles.
AngularJS is a fully client-side framework. AngularJS's templating is based on
bidirectional UI data binding. Data-binding is an automatic way of updating the view
whenever the model changes, as well as updating the model whenever the view
changes. The HTML template is compiled in the browser. The compilation step
creates pure HTML, which the browser re-renders into the live view. The step is
repeated for subsequent page views. In traditional server-side HTML programming,
concepts such as controller and model interact within a server process to produce
new HTML views. In the AngularJS framework, the controller and model states are
maintained within the client browser. Therefore, new pages are capable of being
generated without any interaction with a server.
Ember.js is a client-side JavaScript web application framework based on the model-
view-controller (MVC) software architectural pattern. It allows developers to create
scalable single-page applications by incorporating common idioms and best practices
into a framework that provides a rich object model, declarative two-way data binding,
computed properties, automatically-updating templates powered by Handlebars.js,
and a router for managing application state.
ExtJS is also a client side framework that allows creating MVC applications. It has its
own event system, window and layout management, state management (stores) and
various UI components (grids, dialog windows, form elements etc.). It has its own
class system with either dynamic or static loader. The application built with ExtJS can
either exist on its own (with state in the browser) or with the server (e.g. with REST
API that is used to fill its internal stores). ExtJS has only built in capabilities to use
localStorage so larger applications need a server to store state.
Knockout.js is a client side framework which uses templates based on the Model-
View-ViewModel pattern.
Meteor.js is a full-stack (client-server) JavaScript framework designed exclusively for
SPAs. It features simpler data binding than Angular, Ember or ReactJS,[6] and uses the
Distributed Data Protocol[7] and a publish–subscribe pattern to automatically
propagate data changes to clients in real-time without requiring the developer to
write any synchronization code. Full stack reactivity ensures that all layers, from the
database to the templates, update themselves automatically when necessary.
Ecosystem packages such as Server Side Rendering[8] address the problem of Search
Engine Optimization.
10

Aurelia is a JavaScript client framework for mobile, desktop and web. It is similar to
AngularJS, but is newer, more standards-compliant, and utilizes a modular approach.
Aurelia was written with next-generation ECMAScript.[citation needed]
Vue.js (commonly referred to as Vue; pronounced /vjuː/, like view) is an open-source
progressive JavaScript framework for building user interfaces. Vue developers also
provide Vuex for state management.
React (sometimes styled React.js or ReactJS) is a JavaScript library for building user
interfaces. It is maintained by Facebook, Instagram and a community of individual
developers and corporations. React uses a new language which is a mix of JS and
HTML (a subset of HTML). Several companies use React with Redux (JavaScript
library) which adds state management capabilities, which (with several other
libraries) lets developers create complex applications.[9]
Fulcro is a full-stack library that adopts data-driven principles from Netflix's Falcor,
Facebook's Relay, and Om Next's adaptations of reactive, functional, data-driven
software. It leverages React underneath for raw rendering, gaining all of the
advantages of that platform, but provides a clear full-stack model similar to Redux,
but using immutable data to gain the advantages of functional programming. It has a
pluggable architecture that makes it possible to seamlessly integrate any back-end
resources, and has the distinction of providing a support viewer technology that
allows developers to debug against the real UI state history of an in-the-field client's
session. Websockets are supported as an option and allow one to create the
advanced behaviors of Meteor.js with very little code.[10][better source needed]
Ajax
The most prominent technique currently being used is Ajax.[1] Predominantly using
the XMLHttpRequest/ActiveX Object(deprecated) object from JavaScript, other Ajax
approaches include using IFRAME or script HTML elements. Popular libraries like
jQuery, which normalize Ajax behavior across browsers from different manufacturers,
have further popularized the Ajax technique.
Websockets
WebSockets are a bidirectional stateful real-time client-server communication
technology part of the HTML5 specification, superior to Ajax in terms of
performance[11] and simplicity.
Server-sent events
Server-sent events (SSEs) is a technique whereby servers can initiate data
transmission to browser clients. Once an initial connection has been established, an
event stream remains open until closed by the client. SSEs are sent over traditional
HTTP and have a variety of features that WebSockets lack by design such as
automatic reconnection, event IDs, and the ability to send arbitrary events.[12]
Browser plugins
Although this method is outdated, asynchronous calls to the server may also be
achieved using browser plug-in technologies such as Silverlight, Flash, or Java applets.
Data transport (XML, JSON and Ajax)
10

Requests to the server typically result in either raw data (e.g., XML or JSON), or new
HTML being returned. In the case where HTML is returned by the server, JavaScript on
the client updates a partial area of the DOM (Document Object Model).[13] When raw
data is returned, often a client-side JavaScript XML / (XSL) process (and in the case of
JSON a template) is used to translate the raw data into HTML, which is then used to
update a partial area of the DOM.
10

https://da-14.com/blog/5-best-javascript-frameworks-2017
https://mmikowski.github.io/no-frameworks/
Frameworks and complexity === insanely long cycle times
Top 9 JavaScript frameworks list
Angular.js 2
Generally, Angular.js it is one of the most beloved and used JavaScript frameworks for
building single page applications. It is available as an open source solution and is
supported by Google. The latter is a convincing argument in favor of Angular to
become a front-end solution for a web app. Angular JS is highly preferred for hybrid
mobile application development. Featured with components like overlays, sidebars,
switches and absolute positioned navigation bars, this framework incorporates
dynamic functionality to the application.
Backbone.js
11

Backbone is amongst some of the most popular web development frameworks for
JavaScript developers, and partly for two reasons — it’s easy to understand usability
modules, as well as the very straightforward learning curve. Backbone creates single-
page applications using the most traditional web development libraries. It is built
with the idea in mind that all server-side functions should flow through an API,
minimizing the amount of code that needs to be composed in order to achieve the
same complex functionality of more sophisticated web frameworks.
React.js
React.js was created by the team of Facebook developers and came out in 2013.
Being pretty new in comparison with other JavaScript frameworks it confidently wins
its niche. If you like the user interface of Facebook and Instagram then you might like
React.js too. This very framework is behind the front-end scenes of the two social
giants. There are other companies that benefit from using it: Atlassian, BBC, Coursera,
Dropbox, Flipboard, Netflix, Paypal, WhatsApp.
Embre.js
Introduced in 2011 this open-source JavaScript framework was declared as the best
JavaScript framework for web application development in 2015. Its closest
competitors are Angular and React. Ember could be a good solution for a startup or
for a business looking to build complex web apps. It has a huge online community,
regular updates and wide application of JavaScript that is meant to offer an engaging
user experience. The framework is widely accepted for creating feature-rich web
applications. The most common websites that have been designed using the
framework are LinkedIn, Kickstarter, Blue Apron, and many others.
Aurelia.js
Being a self-proclaimed web development framework, Aurelia makes the process of
site development a creative process. Designed with the latest JS standard, ES6,
Aurelia has the ability to function on all modern browsers. Designed on a module-like
framework, Aurelia has various small and huge libraries that can be used either in
combination or individually, depending upon the kind of application being designed.
11

Meteor.js
With a variety of features for backend, frontend development and database
management, Meteor rank as the most popular JavaScript frameworks. Since its
inception in the year 2012, this framework has grown in terms of performance, UI
design and so on. MeteorJS covers all the phases of software development cycle and
takes care of such glooming processes as linking, files concatenation and others. It is
of current usage in real-time application development for business companies like
Mazda, IKEA, Honeywell and many others.
Vue.js
Introduced back in 2016, Vue has a learning curve that is easier
. The framework delivers two-way data binding, server-side rendering, Vue-CLI and
optional JSX support. It is one the fastest emerging frameworks till date and is a
preferable choice for quick cross-platform solutions.
Polymer
Polymer is another JavaScript framework from Google. With its material web design
and modern outlook, Polymer is one stupefying JavaScript framework that comes
with the ability to create and reuse web components. It is featured with Polymer App
Toolbox that allows you to create and deliver cutting-edge progressive web
applications. The framework is fully interoperable, built for speed and offers support
on all modern day browsers.
Socket
Socket’s gained a lots of momentum in the real-time developer community. With
Socket you can enjoy a fully functional real-time communication between the client
and the server. Socket is divided into two different parts — the first part is a client-
library that runs from the browser, whereas the server-library is built on top of
11

Node.js. Both libraries share a very similar API, and Socket is also event driven; much
like Node.js is. With Socket you can implement real-time streaming of binary, instant
messaging platforms, interactive document collaboration, real-time stats for your
apps and projects (analytics), and so much more.
Remember that the process of choosing a framework depends not only on its
functionality but also how it can be used within your own project.
11

https://da-14.com/blog/5-best-javascript-frameworks-2017
https://mmikowski.github.io/no-frameworks/
Frameworks and complexity === insanely long cycle times
Top 9 JavaScript frameworks list
Angular.js 2
Generally, Angular.js it is one of the most beloved and used JavaScript frameworks for
building single page applications. It is available as an open source solution and is
supported by Google. The latter is a convincing argument in favor of Angular to
become a front-end solution for a web app. Angular JS is highly preferred for hybrid
mobile application development. Featured with components like overlays, sidebars,
switches and absolute positioned navigation bars, this framework incorporates
dynamic functionality to the application.
Backbone.js
12

Backbone is amongst some of the most popular web development frameworks for
JavaScript developers, and partly for two reasons — it’s easy to understand usability
modules, as well as the very straightforward learning curve. Backbone creates single-
page applications using the most traditional web development libraries. It is built
with the idea in mind that all server-side functions should flow through an API,
minimizing the amount of code that needs to be composed in order to achieve the
same complex functionality of more sophisticated web frameworks.
React.js
React.js was created by the team of Facebook developers and came out in 2013.
Being pretty new in comparison with other JavaScript frameworks it confidently wins
its niche. If you like the user interface of Facebook and Instagram then you might like
React.js too. This very framework is behind the front-end scenes of the two social
giants. There are other companies that benefit from using it: Atlassian, BBC, Coursera,
Dropbox, Flipboard, Netflix, Paypal, WhatsApp.
Embre.js
Introduced in 2011 this open-source JavaScript framework was declared as the best
JavaScript framework for web application development in 2015. Its closest
competitors are Angular and React. Ember could be a good solution for a startup or
for a business looking to build complex web apps. It has a huge online community,
regular updates and wide application of JavaScript that is meant to offer an engaging
user experience. The framework is widely accepted for creating feature-rich web
applications. The most common websites that have been designed using the
framework are LinkedIn, Kickstarter, Blue Apron, and many others.
Aurelia.js
Being a self-proclaimed web development framework, Aurelia makes the process of
site development a creative process. Designed with the latest JS standard, ES6,
Aurelia has the ability to function on all modern browsers. Designed on a module-like
framework, Aurelia has various small and huge libraries that can be used either in
combination or individually, depending upon the kind of application being designed.
12

Meteor.js
With a variety of features for backend, frontend development and database
management, Meteor rank as the most popular JavaScript frameworks. Since its
inception in the year 2012, this framework has grown in terms of performance, UI
design and so on. MeteorJS covers all the phases of software development cycle and
takes care of such glooming processes as linking, files concatenation and others. It is
of current usage in real-time application development for business companies like
Mazda, IKEA, Honeywell and many others.
Vue.js
Introduced back in 2016, Vue has a learning curve that is easier
. The framework delivers two-way data binding, server-side rendering, Vue-CLI and
optional JSX support. It is one the fastest emerging frameworks till date and is a
preferable choice for quick cross-platform solutions.
Polymer
Polymer is another JavaScript framework from Google. With its material web design
and modern outlook, Polymer is one stupefying JavaScript framework that comes
with the ability to create and reuse web components. It is featured with Polymer App
Toolbox that allows you to create and deliver cutting-edge progressive web
applications. The framework is fully interoperable, built for speed and offers support
on all modern day browsers.
Socket
Socket’s gained a lots of momentum in the real-time developer community. With
Socket you can enjoy a fully functional real-time communication between the client
and the server. Socket is divided into two different parts — the first part is a client-
library that runs from the browser, whereas the server-library is built on top of
12

Node.js. Both libraries share a very similar API, and Socket is also event driven; much
like Node.js is. With Socket you can implement real-time streaming of binary, instant
messaging platforms, interactive document collaboration, real-time stats for your
apps and projects (analytics), and so much more.
Remember that the process of choosing a framework depends not only on its
functionality but also how it can be used within your own project.
12

avantage non exhaustif …
Pour les développeurs
• Meilleure réutilisation du code à l’aide de composantes/modules
• Le développement est donc simplifier
• Serveur sollicité moins souvent pour l’affichage de l’application
• Utilisation d’une API pour l’échange d’information réduisant le contenu de
l’information envoyée et possibilité de réutilisation sur d’autres applications
Pour le client
• Accès à la page plus rapide une fois l’application chargée en mémoire
• Moins d’information à échanger entre le client et le serveur à chaque appel
• Offre la possibilité de sauvegarder l’application pour un accès hors ligne
• https://angular-university.io/
13
https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-
application-2591588efe58
pros of the Single-Page Application:
SPA is fast, as most resources (HTML+CSS+Scripts) are only loaded once throughout
the lifespan of application. Only data is transmitted back and forth.
The development is simplified and streamlined. There is no need to write code to
render pages on the server.
It is much easier to get started because you can usually kick off development from a
file file://URI, without using any server at all.
SPAs are easy to debug with Chrome, as you can monitor network operations,
investigate page elements and data associated with it.
It’s easier to make a mobile application because the developer can reuse the same
backend code for web application and native mobile application.
SPA can cache any local storage effectively. An application sends only one request,
store all data, then it can use this data and works even offline.
13

https://blog.angular-university.io/why-a-single-page-application-what-are-the-
benefits-what-is-a-spa/
https://www.scalablepath.com/blog/single-page-applications/
https://putaindecode.io/fr/articles/js/webpack/
https://en.wikipedia.org/wiki/Webpack
13

https://blogs.cisco.com/security/a_brief_history_of_malware_obfuscation_part_1_of
_2
https://blogs.cisco.com/security/a_brief_history_of_malware_obfuscation_part_2_of
_2
https://blog.malwarebytes.com/threat-analysis/2013/03/obfuscation-malwares-best-
friend/
https://blogs.cisco.com/security/on_information_entropy
https://blogs.cisco.com/security/real-world-dns-abuse-finding-common-ground
14

var _0x98fd =
["x2Ex6Fx76x65x72x6Cx61x70x62x6Cx61x63x6Bx62x67x2Cx20x2Ex73x6Cx69x64x65x4Cx65
x66x74", "x2Ex77x73x6Dx65x6Ex75x63x6Fx6Ex74x65x6Ex74", "x6Dx65x6Ex75x6Fx70x65x6E",
"x61x64x64x43x6Cx61x73x73", "x6Dx65x6Ex75x63x6Cx6Fx73x65",
"x72x65x6Dx6Fx76x65x43x6Cx61x73x73","x68x61x73x43x6Cx61x73x73",
"x63x6Cx69x63x6B", "x23x6Ex61x76x54x6Fx67x67x6Cx65",
"x6Dx72x67x69x6Ex6Cx65x66x74", "x74x6Fx67x67x6Cx65x43x6Cx61x73x73",
"x2Ex77x73x6Dx65x6Ex75x63x6Fx6Ex74x61x69x6Ex65x72", "x6Fx6E",
"x23x6Ex61x76x54x6Fx67x67x6Cx65x2Cx2Ex6Fx76x65x72x6Cx61x70x62x6Cx61x63x6Bx62x
67",
"x3Cx73x70x61x6Ex20x63x6Cx61x73x73x3Dx22x77x73x6Dx65x6Ex75x2Dx63x6Cx69x63x6B
x22x3Ex3Cx69x20x63x6Cx61x73x73x3Dx22x77x73x6Dx65x6Ex75x2Dx61x72x72x6Fx77x20x6
6x61x20x66x61x2Dx61x6Ex67x6Cx65x2Dx64x6Fx77x6Ex22x3Ex3Cx2Fx69x3Ex3Cx2Fx73x70x
61x6Ex3E", "x70x72x65x70x65x6Ex64",
"x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75x2Cx20x2Ex77x73x6Dx65x6Ex75x2D
x73x75x62x6Dx65x6Ex75x2Dx73x75x62x2Cx20x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx6
5x6Ex75x2Dx73x75x62x2Dx73x75x62", "x68x61x73",
"x2Ex77x73x6Dx65x6Ex75x2Dx6Cx69x73x74x20x6Cx69", "x2Ex6Dx65x67x61x6Dx65x6Ex75",
"x73x6Cx6Fx77", "x73x6Cx69x64x65x54x6Fx67x67x6Cx65",
"x2Ex77x73x6Dx65x6Ex75x2Dx6Cx69x73x74",
"x2Ex77x73x6Dx65x6Ex75x2Dx6Dx6Fx62x69x6Cx65",
"x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75", "x73x69x62x6Cx69x6Ex67x73",
"x77x73x6Dx65x6Ex75x2Dx72x6Fx74x61x74x65",
"x2Ex77x73x6Dx65x6Ex75x2Dx61x72x72x6Fx77", "x63x68x69x6Cx64x72x65x6E",
"x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75x2Dx73x75x62",
"x2Ex77x73x6Dx65x6Ex75x2Dx73x75x62x6Dx65x6Ex75x2Dx73x75x62x2Dx73x75x62",
"x2Ex77x73x6Dx65x6Ex75x2Dx63x6Cx69x63x6B"];
15

$(function() {
var _0x5c8dx1 = $(_0x98fd[0]);
var _0x5c8dx2 = $(_0x98fd[1]);
var _0x5c8dx3 = function() {
$(_0x5c8dx1)[_0x98fd[5]](_0x98fd[4])[_0x98fd[3]](_0x98fd[2])
};
var _0x5c8dx4 = function() {
$(_0x5c8dx1)[_0x98fd[5]](_0x98fd[2])[_0x98fd[3]](_0x98fd[4])
};
$(_0x98fd[8])[_0x98fd[7]](function() {
if (_0x5c8dx2[_0x98fd[6]](_0x98fd[2])) {
$(_0x5c8dx4)
} else {
$(_0x5c8dx3)
}
});
_0x5c8dx2[_0x98fd[7]](function() {
if (_0x5c8dx2[_0x98fd[6]](_0x98fd[2])) {
$(_0x5c8dx4)
}
});
$(_0x98fd[13])[_0x98fd[12]](_0x98fd[7], function() {
$(_0x98fd[11])[_0x98fd[10]](_0x98fd[9])
});
$(_0x98fd[18])[_0x98fd[17]](_0x98fd[16])[_0x98fd[15]](_0x98fd[14]);
$(_0x98fd[18])[_0x98fd[17]](_0x98fd[19])[_0x98fd[15]](_0x98fd[14]);
$(_0x98fd[23])[_0x98fd[7]](function() {
$(_0x98fd[22])[_0x98fd[21]](_0x98fd[20])
});
$(_0x98fd[31])[_0x98fd[7]](function() {
$(this)[_0x98fd[25]](_0x98fd[24])[_0x98fd[21]](_0x98fd[20]);
});
});
16

See also a few tutorials on analyzing obfuscated JavaScript:
Analyzing Malicious JavaScript by Dejan Lukan.
https://resources.infosecinstitute.com/analyzing-javascript/
Advanced obfuscated JavaScript analysis by Daniel Wesemann.
https://isc.sans.edu/diary/Advanced+obfuscated+JavaScript+analysis/4246
JavaScript Obfuscation on InfoSec Handlers Diary Blog.
https://isc.sans.edu/tag.html?tag=javascript&tag=obfuscation
JavaScript Obfuscation - Manual Armor (part 1, part 2) by Aditya K Sood.
https://secniche.blogspot.com/2012/04/javascript-obfuscation-manual-armor-1.html
https://secniche.blogspot.com/2012/04/javascript-obfuscation-manual-armor-2.html
JSDetox
Malzilla
JavaScript Deobfuscator
ExtractScript
JS-Beautifier
JS-Unpack (see also blog)
Rhino Debugger
Firebug
SpiderMonkey
V8
JSNice
PoisonJS
There are a few tools that you might try
when wanting to analyze JavaScript:
Exemple Code with Js fiddle and/or Jsbin
https://stackoverflow.com/questions/30194953/how-to-decode-this-hex-code-
javascript
References:
[1] JSDetox, http://www.relentless-coding.com/projects/jsdetox/.
[2] Detection and Analysis of Drive-by-Download Attacks and Malicious JavaScript
Code,
http://cs.ucsb.edu/~vigna/publications/2010_cova_kruegel_vigna_Wepawet.pdf.
[3] Deobfuscating malicious code layer by layer,
http://www.pandasecurity.com/mediacenter/malware/deobfuscating-malicious-
code-layer-by-layer/.
[4]
https://reverseengineering.stackexchange.com/questions/tagged/javascript+deobfus
cation
https://reverseengineering.stackexchange.com/questions/tagged/javascript+deobfus
cation
17

https://reverseengineering.stackexchange.com/questions/18977/is-deobfuscation-
of-my-javascript-code-hard-or-easy
https://beautifier.io/
https://github.com/denis-ivanov/Jsbeautifier en c#
Advanced JavaScript Deobfuscation via Partial Evaluation
https://github.com/mindedsecurity/JStillery
https://mindedsecurity.github.io/jstillery/#
https://github.com/lelinhtinh
https://github.com/lelinhtinh/de4js
JavaScript Deobfuscator and Unpacker https://lelinhtinh.github.io/de4js/
https://www.dcode.fr/desobfuscateur-javascript
http://jsnice.org/
http://nice2predict.org/
https://github.com/eth-sri/Nice2Predict
https://github.com/eth-sri/UnuglifyJS
https://w3guy.com/online-javascript-code-beautifier/
https://reverseengineering.stackexchange.com/questions/4561/how-to-deobfuscate-
an-obfuscated-javascript-file-like-this
There are a few tools that you might try when wanting to analyze JavaScript:
JSDetox
Malzilla
JavaScript Deobfuscator
ExtractScript
JS-Beautifier
JS-Unpack (see also blog)
Rhino Debugger
Firebug
SpiderMonkey
V8
17

JSNice
PoisonJS
See also a few tutorials on analyzing obfuscated JavaScript:
Analyzing Malicious JavaScript by Dejan Lukan.
https://resources.infosecinstitute.com/analyzing-javascript/
Advanced obfuscated JavaScript analysis by Daniel Wesemann.
https://isc.sans.edu/diary/Advanced+obfuscated+JavaScript+analysis/4246
JavaScript Obfuscation on InfoSec Handlers Diary Blog.
https://isc.sans.edu/tag.html?tag=javascript&tag=obfuscation
JavaScript Obfuscation - Manual Armor (part 1, part 2) by Aditya K Sood.
https://secniche.blogspot.com/2012/04/javascript-
obfuscation-manual-armor-1.html
https://secniche.blogspot.com/2012/04/javascript-obfuscation-
manual-armor-2.html
And, finally, a few questions that have been already answered here:
Analyze obfuscated JavaScript code?
Analyzing highly obfuscated JavaScript
Try to deobfuscate multi layered javascript
What is a good tools to reverse the effects of Minify on JavaScript?
Or, more generally, search for the javascript and deobfuscation tags (link to the
search).
http://dean.edwards.name/packer/
https://github.com/mishoo
https://github.com/mishoo/UglifyJS
https://github.com/mishoo/UglifyJS2
http://lisperator.net/uglifyjs/
17

https://obfuscator.io/
https://github.com/javascript-obfuscator
17

DÉMO (Wouahhh Malade …)
https://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
https://en.wikipedia.org/wiki/List_of_JavaScript_libraries
http://jster.net/
Web-application related (MVC, MVVM)
The Ultimate Guide to JavaScript Frameworks
https://javascriptreport.com/the-ultimate-guide-to-javascript-frameworks/
https://fr.wikipedia.org/wiki/Compilateur_source_%C3%A0_source
Un compilateur source à source, transpileur ou transcompilateur est un type de
compilateur qui prend le code source d'un langage de programmation et le compile
dans un autre langage de programmation.
Un compilateur source-à-source opère sur deux langages avec approximativement le
même niveau d'abstraction, alors qu'un compilateur traditionnel compile un langage
de haut niveau vers un langage de bas niveau.
https://en.wikipedia.org/wiki/Source-to-source_compiler
18

List of languages that compile to JS
https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS
18

L'envers de la médaille . . .
La divulgation d’information sensible
• Accès à des URL (Endpoint)
• Augmente terriblement la surface d’attaque
• Retrouver des mots de passe en clair
• Retrouver des clés secrètes
• Comme des informations d’identification à différents services
• Accès aux messages d’erreur
19
19

L'envers de la médaille . . .
20
20

21
Capture écran prise le 12-09-2018 à 10h47
21

. . . l'envers de la médaille
Les fichiers map, ça vous dit quelque chose?
• Aident à déboguer des scripts minifiés
• Code minifié ne veut pas dire illisible
• Le navigateur doit tout de même être capable de l’interpréter
• Permettent de récupérer le code source original
• Parfois oubliés en production et accessibles sans être authentifiés
• Permettent d’exécuter l’application localement
• Possibilité de trouver des failles de sécurité
• Accès à certains fichiers non minifiés
22
https://www.thecssninja.com/javascript/source-mapping
https://developer.mozilla.org/fr/docs/Outils/D%C3%A9bogueur/Comment/Utiliser_u
ne_source_map
https://stackoverflow.com/questions/27345520/source-maps-files-in-production-is-
it-safe#
https://github.com/mozilla/source-map
https://developers.google.com/web/tools/chrome-devtools/javascript/source-maps
22

23
https://en.wikipedia.org/wiki/Webpack
You need to use a minifier that's capable of creating source maps. For the most
popular options, see our preprocessor support section. For an extended view, see the
Source maps: languages, tools and other info wiki page.
The following types of preprocessors are commonly used in combination with Source
Maps:
Transpilers (Babel, Traceur)
Compilers (Closure Compiler, TypeScript, CoffeeScript, Dart)
Minifiers (UglifyJS)
23

Autres problèmes du SPA
• Logique de l’application incluse dans le JavaScript téléchargé
• Téléchargement de toute l’application et non du visuel nécessaire
• Peut créer des fichiers très volumineux (ex : 2,70 Mo)
• Ralentir l’ordinateur du client
• Ralentir le serveur si l’application est utilisée par plusieurs personnes
• Premier chargement très long
24
24

Comment y remédier
• Ne retourner que les informations nécessaires à l’affichage de l’application
• Utiliser un modèle MVC pour isoler la logique de l’application
• Différencier les environnements de développement et de production
• Minifier et « obfusquer » le code avant la mise en production
• Ne pas rendre le code original accessible
• S’assurer de retirer les commentaires du code en production
• Désactiver les SourceMap
• Faire une vérification de ce qui est accessible à partir du code
25
25

Comment y remédier
• OpenID Connect Relying Party and OAuth 2.0 Resource Server for Apache
HTTP Server 2.x
https://github.com/zmartzone/mod_auth_openidc/wiki/Single-Page-
Applications
• La super présentation OWASP sur l’OIDC et l’OAUTH2
https://www.slideshare.net/MarcAndrTousignant/introduction-oauth-20-et-
openid-connect-10-102478531
• Faire preuve de recul lors des choix pour la gestion des identités et des
mécanismes utilisés et faire un WebApi détaché totalement l’identification afin
de ne gérer que les autorisations (AuthN # AuthZ)
26
26

Comment y remédier
• OWASP Security Knowledge Framework
The OWASP Security Knowledge Framework is intended to be a tool that is
used as a guide for building and verifying secure software. It can also be used
to train developers about application security. Education is the first step in the
Secure Software Development Lifecycle.
https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework#t
ab=Main
• XSS (Cross Site Scripting) Prevention Cheat Sheet
XSS Prevention Framework Cheat Sheet
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Ch
eat_Sheet
• https://www.owasp.org/index.php/XSS_Prevention_Framework_Cheat_Sheet
27
27

Ce qu’il faut retenir
• Les anciennes méthodes de développement avaient de bonnes pratiques en
matière de sécurité et il ne faut pas les oublier
• Le modèle MVC est encore disponible pour les SPA
• Google avec Angular a réintroduit le MVC
• Comparer les Frameworks et choisir celui dont vous avez vraiment besoin
• Ce n’est pas parce que c’est hotque l’on doit absolument l’utiliser, ce
n’est pas nécessairement plus sécuritaire
29
Peut être une façon hybride pour avoir l’avantage
des deux mondes, mais cela sera pour une
prochaine fois … ;)
https://www.slideshare.net/MehmetAliTastan/spa-vs-mpa
https://stackoverflow.com/questions/21862054/single-page-application-advantages-
and-disadvantages#
Let's look at one of the most popular SPA sites, GMail.
1. SPA is extremely good for very responsive sites:
Server-side rendering is not as hard as it used to be with simple techniques like
keeping a #hash in the URL, or more recently HTML5 pushState. With this approach
the exact state of the web app is embedded in the page URL. As in GMail every time
you open a mail a special hash tag is added to the URL. If copied and pasted to other
browser window can open the exact same mail (provided they can authenticate). This
approach maps directly to a more traditional query string, the difference is merely in
the execution. With HTML5 pushState() you can eliminate the #hash and use
completely classic URLs which can resolve on the server on the first request and then
load via ajax on subsequent requests.
2. With SPA we don't need to use extra queries to the server to download pages.
The number of pages user downloads during visit to my web site?? really how many
29

mails some reads when he/she opens his/her mail account. I read >50 at one go. now
the structure of the mails is almost the same. if you will use a server side rendering
scheme the server would then render it on every request(typical case). - security
concern - you should/ should not keep separate pages for the admins/login that
entirely depends upon the structure of you site take paytm.com for example also
making a web site SPA does not mean that you open all the endpoints for all the
users I mean I use forms auth with my spa web site. - in the probably most used SPA
framework Angular JS the dev can load the entire html temple from the web site so
that can be done depending on the users authentication level. pre loading html for all
the auth types isn't SPA.
3. May be any other advantages? Don't hear about any else..
these days you can safely assume the client will have javascript enabled browsers.
only one entry point of the site. As I mentioned earlier maintenance of state is
possible you can have any number of entry points as you want but you should have
one for sure.
even in an SPA user only see to what he has proper rights. you don't have to inject
every thing at once. loading diff html templates and javascript async is also a valid
part of SPA.
Advantages that I can think of are:
rendering html obviously takes some resources now every user visiting you site is
doing this. also not only rendering major logics are now done client side instead of
server side.
date time issues - I just give the client UTC time is a pre set format and don't even
care about the time zones I let javascript handle it. this is great advantage to where I
had to guess time zones based on location derived from users IP.
to me state is more nicely maintained in an SPA because once you have set a variable
you know it will be there. this gives a feel of developing an app rather than a web
page. this helps a lot typically in making sites like foodpanda, flipkart, amazon.
because if you are not using client side state you are using expensive sessions.
websites surely are extremely responsive - I'll take an extreme example for this try
making a calculator in a non SPA website(I know its weird).
Updates from Comments
It doesn't seem like anyone mentioned about sockets and long-polling. If you log out
from another client say mobile app, then your browser should also log out. If you
don't use SPA, you have to re-create the socket connection every time there is a
redirect. This should also work with any updates in data like notifications, profile
update etc
An alternate perspective: Aside from your website, will your project involve a native
mobile app? If yes, you are most likely going to be feeding raw data to that native app
from a server (ie JSON) and doing client-side processing to render it, correct? So with
29

this assertion, you're ALREADY doing a client-side rendering model. Now the question
becomes, why shouldn't you use the same model for the website-version of your
project? Kind of a no-brainer. Then the question becomes whether you want to
render server-side pages only for SEO benefits and convenience of
shareable/bookmarkable URLs
29

Ce qu’il faut retenir
The Single Page
Interface Manifesto
http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php
30
The Single Page Interface Manifesto
Updated: Sept. 21, 2015
Origins of web technology
When Tim Berners Lee invented web he was looking for a system to publish scientific
documents remotely accessible, visually attractive, easy to code and easy to use for a
non-technical person.
In a scientific document, external cites to other documents is indispensable, in order
that the reader may optionally develop the theme in question.
For these reasons the World Wide Web was conceived as a page (document) based
system with hyperlinks.
Initially the Web was a world of static pages and links but soon the generation of
dynamic pages and in general the use of the Web as a support for designing web-
based applications complicated everything.
The arrival of web applications
For many years there has been a strong effort to adapt the web paradigm of pages
and links to application development. In a web application the Berners' view of static
documents and simple links do not exist.
Different application development approaches have been happening:
Model 1: direct translation of the original model of pages and links, where pages are
30

dynamically generated.
Model 2 o MVC: now links are not directly pointing to a concrete target page, in this
case a controller decide what the next page is depending on the operations taken
place in page transition.
MVC based on components (Model 3?): is the sophisticated version of Model 2
simulating how desktop applications work. It is based on components and events, so
any user action implies the complete rebuild and reload of the page partially
changing some part according with the action performed. The page and page
transition is now managed by components which now what changes take place
according to the event, simulating how components work on desktop GUI
programming.
In recent years the AJAX technique has been introduced, this technique with the help
of JavaScript allows partial changes in pages obtaining new data from server without
reloading. In spite of partial page change technique is long before the introduction of
XMLHttpRequest in Internet Explorer (base of AJAX programming), it has been the
boost of its massive use.
Now millions of web sites and web applications use AJAX to provide a better
experience to end users thanks to more responsive user interfaces partially avoiding
the annoying page reloads.
In spite of massive use of AJAX, we can say the Web follows a development model we
could name as "Model 2 (MVC) enriched with AJAX". When using AJAX, "Model 3"
has not much sense because AJAX largely reduces the need of page management
based on components. Because AJAX is usually used alongside components (not
necessarily present in Model 2), we may classify the current state of art of web
development as Model 3.5, where page navigation is partially avoided in case of
minor state transitions performed by AJAX and JavaScript.
What are the disadvantages of page based navigation and development?
Every web developer knows how problematic is page navigation in a web application,
besides of bandwidth wasting and process time rebuilding entire pages more
problems make web development painful like unwanted caching, back/forward
buttons, desynchronized forms caused by the "form auto-fill" feature of some
browsers and so on. It is not uncommon to see web applications that hide the menus
and buttons of the browser or using frames or iframes (e.g. banks) to avoid the
problem of Back/Forward buttons.
Page based development forces a style of coding weird, repetitive (plenty of includes)
and inefficient (both bandwidth and computing power) not found in desktop
development.
What is what prevents intensive use of AJAX?
In the field of web development we are used to distinguish two kind of web solutions:
web applications and web sites.
In the first case AJAX is becoming more and more used because this kind of
applications do not share some requisites imposed for web sites. In web sites
30

intensive use of AJAX is a problem.
In public web sites end users are used to the page concept, bound to the pages some
requisites and services are required in any web site like:
Bookmarking: Every web page has a different URL, this URL can be saved as
bookmark. Because AJAX can partially change the page the URL is the same, the end
user cannot save as bookmark a concrete view (state) of the page.
Search Engine Optimization (SEO): Any web site wants to be fully indexed by search
engines like Google Search. Current crawlers see the Web as Web 1.0, that is,
JavaScript code is fully ignored, thereby any partial change performed via AJAX
loaded from server is not executed then not indexed by crawlers traversing the web
site.
Services based on page visits: For instance advertisement services like Google
AdSense and page visit monitoring such as Google Analytics, in both cases the
number of page loads is important. Therefore any partial change done by AJAX does
not count as a new visit.
Occasional need of pop-pup windows
Because these requisites intensive AJAX is discouraged in web sites.
However the difference between a "web site" and a "web application" is becoming
smaller because almost any web site is a sort of "web application"...
Should we give up AJAX-intensive applications?
NO.
There are technical solutions for all above listed requisites.
Development of web sites based on a single Web page (SPI), is it possible?
YES !
This is the time to start this transition, developers and end users all of us will gain. We
have the technology and modern browsers are qualified to achieve this objective.
To succeed in this "new" way of web development we must to accomplish all of
previous requisites of any web site.
Goodbye pages, welcome states
In an web application without JavaScript, state sequence is equivalent to pages, in a
SPI application any partial change implies a new "state" of "the page". Among states
we can distinguish two categories of states:
Fundamental states
Secondary states
Differencing between both state types is very important, because fundamental states
will become web pages when needed. Fundamental and secondary differentiation is
web site dependent.
To better understand both types of states we can study a real example: login
validation.
In a classic page based applications typical login is built by using two pages, one for
user and password and one showing user options if login validation was correct; the
login page will be reloaded showing some error messages alongside the login form
30

when login entry is wrong.
In a SPI web, initial login and the user options page could be the fundamental states,
and error messages alongside login could be secondary states.
Another example, a web site based on pages to be converted to SPI, in this case
fundamental states will be the pages and secondary states will be page states with
minor changes, not important enough for bookmarking or to be traversed by
crawlers.
Single Page Interface and Bookmarking
Different pages have different URLs, following the SPI route how can we change a
state and at the same time the URL without reloading to allow this new state can be
bookmarked by end users?.
There is a trick, using the "reference" part of URLs ("hash fragment", shebang or
hashbang), this is the last part, if present, following the # character. This reference is
used to scroll the page to the concrete location specified by some <a
name="ref"></a> mark. This reference part if changed does not reloads the page,
hence if the URL reference is changed by using window.location alongside the page
state (in this case this new state is "fundamental") with JavaScript and AJAX, then no
reload is performed. Because the URL and the fundamental state have changed, end
users can save this URL, in some way containing the new state info, as bookmark.
When end user wants to come back again to the bookmarked page, the target state is
specified in the reference part of the URL, the server will be requested, unfortunately
the reference part is not sent to the server because reference part does nothing to do
with remote location using HTTP, hence we will need a post-load process.
The server will return an initial page in which the target state is not the specified,
however the window.location object contains the original URL including the reference
part. When loading the target page we can detect with JavaScript whether
window.location contains a reference part and whether this reference has the
required target state info, if true we can rewrite the URL adding some kind of normal
parameter to specify the target state to load. Because the URL has actually changed a
new server request is executed, this time the state to load is in a parameter and the
server returns a new page with the required state.
Another option, better than hashbangs, arises with the advent of HTML 5, the HTML
5 History API.
Single Page Interface and Search Engine Optimization (SEO)
The easiest way to get our web site is processed by search engine crawlers is to offer
two different navigation modes, SPI for end users, pages for web crawlers.
The next example shows a link with this idea:
<a href="URL page" onclick="return false">…</a>
This link will do nothing in a browser with JavaScript enabled because navigation is
disabled by "return false" of onclick attribute, but when a bot indexes this link ignores
the onclick attribute because JavaScript code is not executed and will process the
specified URL as the next page to process.
30

In the field of a SPI application, URLs being used for page/state navigation must
contain the target state, the same type of URLs used in SPI bookmarking that is using
the reference part to indicate the target state, or the target is directly written as a
normal parameter, the later is preferred because it avoids a server request, of course
"pretty URLs" can also be used.
Currently Google already crawls "AJAX URLs", that is, URLs containing the target state
in the reference part following #! as specified in Making AJAX Applications Crawlable,
in this case the web site/application must return the expected page being requested
with a _escaped_fragment_ parameter.
At the same time the SPI web framework can add specific code to the onclick handler
before return false or can bind an event listener to the link being used for state/page
navigation, registered with addEventListener or attachEvent depending on the
browser. This event listener will execute some action to command the server, usually
using AJAX, to change the page state. When the link is clicked this state change is not
a new page because the attribute onclick="... return false" avoids the default
behavior.
The technique described before is the simplest and immediate by using visible links
compatible with bots and SPI. You can ever separate both functions, for instance
using hidden links for end users but not for bots alongside other clickable elements to
change SPI states by using JavaScript invisible for bots.
The most important feature of a SPI capable framework is page generation as HTML
with the required state on loading time and at the same time the same change state
must be performed with JavaScript and partial page updating. These requisites are
fundamental to provide SPI and page simulation.
SPI and Back/Forward buttons
Back/Forward buttons are a source of problems on conventional page based web
sites and should be avoided as soon as possible. In spite of users are used to avoid
Back and Forward buttons when submitting a form with user data (because it carries
the risk of buying twice the same plane ticked or book), use of Back/Forward buttons
is very widespread.
Apparently the SPI paradigm breaks the traditional way of navigation of a web site,
because in theory Back/Forward buttons has no sense in SPI (no pages) and web
browsers do not provide a good control of these buttons.
This is not fully true, Back/Forward behavior can be simulated, instead of page
navigation Back/Forward (and history navigation in general) can be used to change
the current state to the previous/forward state. In this case a JavaScript code can
detect when the reference part of the URL changes and requests the application to
change the state accordingly. Because the browser does not change the page your
application is now fully responsible of Back/Forward behavior avoiding the typical
problems of unexpected Back/Forward use of end users when submitting a form,
now in SPI there is no such form and no uncontrolled page navigation by the web
application/web site.
30

SPI and services based on page visits
Ads services and page visit counters are based on how many pages have been loaded.
In both cases you can use hidden <iframe> elements containing an empty web page
with the required scripts to execute this kind of services.
In the case of advertisement services such as Google AdSense, dynamic insertion of
<iframe> implies loading new ads therefore every change state could imply a new
reload of <iframe> with ads. Google AdSense seems to detect when the AdSense
script is executed within a <iframe> and takes into account the contents of the
container page. It may be desirable to add some kind of parameter that identifies the
fundamental state that is loading the <iframe>.
In the case of visit counters, we can use them to monitor user visits to fundamental
states of our SPI web site. In this case we need a hidden <iframe> containing an
empty web page with the monitoring scripts. With a simple parameter we can
indicate the fundamental state being visited. Our <iframe> should be global (always
the same in the page). When the page is first loaded, the fundamental state being
loaded (specified in URL) should be indicated to the <iframe> with a parameter. After
page loading, every fundamental state change could be notified to <iframe> changing
the URL via JavaScript according to the new fundamental state, this URL change will
cause a reload of <iframe> (indicating a new visit).
SPI and pop-up windows
When a new page window is created the SPI model is broken. Fundamentalism is bad,
there is no problem if the state of this new window has nothing to do with the state
of the parent window, in this case pop-up windows are fine.
The problem arises when any action performed on the pop-up window (modal or not
modal) has some influence on the parent window, coordination between pages is
complicated. For instance there is no a web standard to create modal windows
because the page concept has traditionally always been an independent element and
therefore its life cycle is difficult to coordinate from another page.
Fortunately this problem has solution for some time in SPI, you can simulate modal or
not modal windows inside the same web page, no new real page window is created.
In the case of non-modal windows, any HTML element with absolute positioning can
be a "non-modal window" and you can create modal windows by using absolute
positioning, controlling z-index and opacity of elements "on top" of the page ("modal
layers"). These solutions are valid in a SPI context.
With a little effort, even the state which shows a modal window may be a
fundamental state and therefore navigable by search engine bots.
A cultural shift for web developers
Most of web developers (and web frameworks) think the Web as based on pages,
page reduction to a single page implies a radical change of mind and how we make
web sites and applications. This change is not so radical thanks to AJAX, AJAX is today
mainstream and has reduced the number of pages of typical web sites, in summary it
has brought us near of this "new" SPI development model.
30

In the new SPI web the <form> tag disappears and in general the need of sessions
used as data managers following page sequences. Now the protagonist is the page
client with some symmetry in server (the page in server). In fact, because we get rid
of page coordination with sessions we are freed of a source of problems like the bad
practice of some users who open several windows with the same page, this practice
usually breaks the session and the application in general.
SPI programming is based on events the same as in desktop, because in desktop most
of applications runs in the same frame window and when child windows exist these
are fully managed by the main window and genuinely modal.
Following the paradigm evolution of web development, this "new" approach could be
named Model 4.
A cultural shift for end users?
Not very much, with bookmarking and Back/Forward simulation end users are not
going to differentiate a SPI web site and the same page based, furthermore the SPI
site will be more responsive and the typical blinking and scrolling of page navigation
is removed.
Technical viability today
This manifesto is not a statement of intentions but the expression of the desire to
promote a "new" way of building websites that are already real. The above technical
study has always had the Java web framework ItsNat as the technological base of SPI
web site development. In spite of ItsNat was conceived from day one to this kind of
applications/sites, previous techniques could be applied with other web frameworks
or these frameworks could evolve to provide facilities for this kind of SPI web sites
with page simulation requirements.
Some requirements of these SPI web sites to be able of replacing traditional page
based web sites, such as page simulation of fundamental states on loading time, are
just possible with server centric web frameworks because HTML rendering must be
done in server on load time. HTML rendering on load time and the same dynamically
loaded and inserted with JavaScript are the key characteristics of a web framework
ready to build SPI web sites. Client centric frameworks could have a major role for the
realization of so-called secondary states.
Two real world examples
The web innowhere.com/jnieasy
It is made with ItsNat in server and a good example of SPI web site because it sums
up all requirements of a SPI web site, explained in this document, to be a satisfactory
substitute of a traditional site. In fact, the new SPI version replaced, with no
significative aesthetic of functional change, the previous version based on pages. It is
based on hashbangs.
Characteristics
Single Page Interface: Back and Forward buttons are simulated changing to previous
or forward visited state.
Fundamental states can be saved as bookmarks.
30

SEO compatible: fundamental states are reachable with JavaScript disabled including
a modal window.
The hashbang #! format is used, that is, Google SEO compatible "AJAX URLs", the
page is also requested following the Google convention of _escaped_fragment_
parameter. For instance this state is crawled by Google requesting this URL.
Works with JavaScript disabled.
Shows an ads banner based on Google AdSense
Despite being SPI, browsing through fundamental states is monitored by Google
Analytics by using a hidden <iframe> which URL changes when the current
fundamental state changes.
A simulated modal window avoids creating a new window page, this simulated
window is also reachable with a direct URL or a hashbang version with text already in
markup on load time consequently SEO compatible.
The web www.itsnat.org
It is also made with ItsNat in server. In this case JavaScript History API is used. This is
the most perfect approach to convert a conventional web site to a SPI SEO
compatible version. If History API is not supported by a concrete old browser,
conventional page navigation is automatically used. All modern web browsers
support the JavaScript History API. The SPI characteristics of this web site are basically
the same as the previous example.
The Manifesto in other languages
Spanish
Note: these translations may be slightly out of date because this manifesto is "alive".
Ukranian thanks to Mario Pozner
Russian thanks to Andrey Geonya
Serbo-Croatian thanks to Jovana Milutinovich
Slovakian translation thanks to Knowledge Team
German thanks to Valeria Aleksandrova.
Romanian translation provided by Science Team.
Macedonian thanks to Katerina Nestiv
Hungarian thanks to Elana Pavlet
Estonian thanks to Valerie Bastiaan
Links pointing to the manifesto
Discussion at DZone
Discussion at TheServerSide.com
Discussion at YCombinator.com
Discussion at JavaHispano.org (in Spanish)
Modern Principles in Web Development presentation based on the SPI manifesto
30

33
Merci beaucoup!
N’hésitez pas si vous avez des questions!
33

https://www.paulirish.com/
https://github.com/kangax
https://kangax.github.io/compat-table/es6/
https://fr.wikipedia.org/wiki/Polyfill
https://stackoverflow.com/questions/6599815/what-is-the-difference-between-a-shim-and-
a-polyfill
https://github.com/es-shims/es5-shim
https://en.wikipedia.org/wiki/Progressive_enhancement
https://fr.wikipedia.org/wiki/Am%C3%A9lioration_progressive
https://en.wikipedia.org/wiki/Razorfish_(company)
https://fr.wikipedia.org/wiki/Exp%C3%A9rience_utilisateur
https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
https://en.wikipedia.org/wiki/Adaptive_web_design Adaptive web design (AWD)
https://en.wikipedia.org/wiki/Responsive_web_design responsive web design (RWD)
A shim is any piece of code that performs interception of an API call and provides a
layer of abstraction. It isn't necessarily restricted to a web application or
HTML5/CSS3.
A polyfill is a type of shim that retrofits legacy browsers with modern HTML5/CSS3
features usually using Javascript or Flash.
Answering your specific question, call it your directory shims if you want to keep
the directory generic.
34

ASP.NET - Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET
https://msdn.microsoft.com/en-us/magazine/dn463786.aspx
https://github.com/MikeWasson/MoviesSPA
Another approach to webapplication fingerprinting
Another approach to webapplication fingerprinting
It has been always important to fingerprint webapplication versions, but now in light
of the recent Drupalgeddon attacks (Yet Another Drupal RCE Vulnerability and More
Threat Hunting with User Agent and Drupal Exploits) it is even more important.
Naturally we can detect the website by just checking the version number, but that’s
not always that precise. There are a lot of applications that disable version
identification or give false information, which would give a lot of false positives for
possible vulnerabilities.
Websites can be identified using files like README, stylesheets, templates and other
static files. Some existing tools identify version information from the outside using
these, but results are not always that precise. They depend often on a (small) pre-
generated database of hashes of files. A while ago I worked on another approach,
using the original (git) repositories. The small (proof of concept) tool called Identify
(http://github.com/dutchcoders/identify) uses not just a predefined list of hashes,
but uses the original opensource repository. Being up to date to the latest version is
important, and using the actual repositories will keep the tool actual. Plugins for
applications like Wordpress are also within public repositories (eg
35

http://plugins.svn.wordpress.org/) and can be probed in the same manner.
Another advantage of using the repositories is that semantic versioned tags are being
used, which makes it easy to identify accompanying vulnerabilities against the CVE
database.
Identify first clones the (git) repository of the opensource content management
system. Next it will do several http requests (using a predefined list, this is one of the
improvements that can be made) against the target website, generate a hash and
compare it against all other hashes in the repository. Those resulting files and hashes
will be stored in a list, narrowing down the amount possible versions and outputting
the results.
As this is just a proof of concept, I’m working on some additions to this tool. First I’d
like to generate a database containing relevant hashes of static files of several
repositories, which will be updated on each start. Using this database and comparing
all files and hashes we could narrow the list down of uniquely identifying applications
and versions, and therefore the amount of requests we need to do on the target site
to identify. Less requests are better.
If the list has been narrowed down to just a single version, the next step will be to
implement the CVE database to show the vulnerabilities to that specific version.
35

Le SPA est-il faillible? (avec notes)

Recommandé

Recommandé

Contenu connexe

Dernier

Dernier (20)

En vedette

En vedette (20)

Le SPA est-il faillible? (avec notes)