Quels détails techniques un programmeur d’une application Web devrait-il prendre en compte avant de rendre le site public?

Quelles sont les choses qu'un programmeur implémentant les détails techniques d'une application Web devrait considérer avant de rendre le site public? Si Jeff Atwood peut oublier HttpOnly biscuits , sitemaps , et demande intersites falsifications tous dans le même site , ce qui est important ce que je pourrais être oubliais aussi?

J'y réfléchis du point de vue d'un développeur Web, de telle sorte que quelqu'un d'autre crée le design et le contenu réels du site. Ainsi, bien que la convivialité et le contenu puissent être plus importants que la plate-forme, vous, les programmeurs, n’avez que très peu à dire. Ce qui vous préoccupe, c’est que votre implémentation de la plate-forme soit stable, fonctionne bien, soit sécurisée et réponde à tous les autres objectifs de l’entreprise (par exemple, ne pas coûter trop cher, prendre trop de temps à construire, et se classer aussi bien avec Google contenu prend en charge).

Pensez à cela du point de vue d'un développeur qui a travaillé sur des applications de type intranet dans un environnement assez fiable et qui est sur le point de se lancer et de créer un site potentiellement populaire pour le monde entier.

De plus, je cherche quelque chose de plus spécifique qu'une simple réponse vague aux "standards du Web". Je veux dire, HTML, JavaScript et CSS sur HTTP sont pratiquement acquis, en particulier lorsque j'ai déjà précisé que vous étiez un développeur Web professionnel. Alors, au-delà de ça, quelles normes? Dans quelles circonstances et pourquoi? Fournissez un lien vers la spécification de la norme.

L'idée ici est que la plupart d'entre nous devraient déjà savoir la plupart de ce qui est sur cette liste. Mais il se peut qu'il y ait un ou deux points que vous n'avez pas encore examinés, que vous ne comprenez pas bien ou dont vous n'avez peut-être jamais entendu parler.

Interface et expérience utilisateur

• Sachez que les navigateurs appliquent les normes de manière incohérente et que votre site fonctionne raisonnablement bien sur tous les principaux navigateurs. Testez au minimum un moteur Gecko récent ( Firefox ), un moteur WebKit ( Safari et certains navigateurs mobiles), Chrome , vos navigateurs IE pris en charge (tirez parti des images VPC de compatibilité des applications ) et Opera . Prenez également en compte la manière dont les navigateurs rendent votre site sous différents systèmes d'exploitation.
• Pensez à la façon dont les gens pourraient utiliser le site autrement que par les principaux navigateurs: téléphones portables, lecteurs d'écran et moteurs de recherche, par exemple. - Quelques informations d'accessibilité: WAI et Section508 , Développement mobile: MobiForge .
• Staging: comment déployer des mises à jour sans affecter vos utilisateurs. Ayez un ou plusieurs environnements de test ou intermédiaires disponibles pour implémenter les modifications apportées à l'architecture, au code ou au contenu intégral, et assurez-vous qu'ils peuvent être déployés de manière contrôlée, sans rien casser. Utilisez un moyen automatisé pour déployer les modifications approuvées sur le site actif. Ceci est le plus efficacement implémenté conjointement à l'utilisation d'un système de contrôle de version (git, Subversion, etc.) et d'un mécanisme de construction automatisé (Ant, NAnt, etc.).
• Ne pas afficher les erreurs indésirables directement à l'utilisateur.
• Ne mettez pas les adresses e-mail des utilisateurs en texte brut, car ils seront expulsés du spam.
• Ajoutez l'attribut rel="nofollow"aux liens générés par l'utilisateur pour éviter le spam .
• Établissez des limites réfléchies sur votre site - cela appartient également à la sécurité
• Apprenez à faire de l'amélioration progressive .
• Rediriger après un POST si ce POST a réussi, pour empêcher une actualisation de soumettre à nouveau.
• N'oubliez pas de prendre en compte l'accessibilité. C'est toujours une bonne idée et dans certaines circonstances, c'est une obligation légale . WAI-ARIA et WCAG 2 sont de bonnes ressources dans ce domaine.
• Lire Ne me faites pas penser .

Sécurité

• Cela fait beaucoup de choses à digérer, mais le guide de développement OWASP couvre la sécurité du site Web de haut en bas.
• Connaître Injection, en particulier l' injection SQL, et savoir comment l'éviter.
• Ne faites jamais confiance aux entrées de l'utilisateur, ni à tout autre élément de la demande (qui inclut les cookies et les valeurs de champs de formulaire masqués!).
• Hachez les mots de passe en utilisant du sel et utilisez des sels différents pour vos lignes afin de prévenir les attaques arc-en-ciel. Utilisez un algorithme de hachage lent, tel que bcrypt (testé dans le temps) ou scrypt (encore plus puissant, mais plus récent) ( 1 , 2 ) pour stocker les mots de passe. ( Comment stocker en toute sécurité un mot de passe ). Le NIST approuve également PBKDF2 pour le hachage des mots de passe "et son approbation FIPS dans .NET (plus d’informations ici ). Évitez d’ utiliser directement la famille MD5 ou SHA.
• N'essayez pas de créer votre propre système d'authentification sophistiqué . C'est une chose tellement facile de se tromper de manière subtile et indestructible et vous ne le saurez même pas avant d' avoir été piraté.
• Connaître les règles de traitement des cartes de crédit . ( Voir aussi cette question )
• Utilisez SSL / TLS / HTTPS pour tous les sites où des données sensibles sont entrées (telles que les informations d'identification, les informations personnellement identifiables, les informations de carte de crédit). Let's Encrypt est une autorité de certification gratuite qui peut vous aider.
• Empêcher le détournement de session .
• Évitez les scripts intersites (XSS).
• Évitez les falsifications de requêtes intersites (CSRF).
• Évitez le détournement de clic .
• Gardez votre système (s) à jour avec les derniers correctifs.
• Assurez-vous que vos informations de connexion à la base de données sont sécurisées.
• Tenez-vous au courant des dernières techniques d'attaque et des vulnérabilités affectant votre plate-forme.
• Lisez le manuel de sécurité du navigateur Google .
• Lisez le manuel du pirate d'application Web .
• Considérons le principe du moindre privilège . Essayez d’exécuter votre serveur d’applications en tant qu’utilisateur non root . ( exemple de tomcat )
• Utilisez rel="noopener noreferrer"tous les liens fournis par les utilisateurs target="_blank"pour empêcher JavaScript sur la page de destination de rediriger votre page vers un autre site, tel qu'une fausse page de connexion. Plus d'informations
• Pensez à utiliser une politique de sécurité du contenu stricte .

Performance

• Implémentez la mise en cache si nécessaire, comprenez et utilisez correctement la mise en cache HTTP ainsi que le manifeste HTML5 .
• Optimiser les images - n'utilisez pas une image de 20 Ko pour un arrière-plan répété.
• Compressez le contenu pour plus de rapidité, voir brotli , gzip / deflate ( dégonfler, c'est mieux ).
• Combinez / concaténez plusieurs feuilles de style ou plusieurs fichiers de script pour réduire le nombre de connexions de navigateur et améliorer la capacité de gzip à compresser les duplications entre fichiers.
• Jetez un coup d'œil sur le site Yahoo Exceptional Performance (Performances exceptionnelles de Yahoo) , avec de nombreuses recommandations, y compris l'amélioration des performances front-end et leur outil YSlow (nécessite Firefox, Safari, Chrome ou Opera). En outre, la vitesse de page de Google (utilisation avec extension de navigateur ) est un autre outil de profilage des performances qui optimise également vos images.
• Utilisez les images-objets CSS pour les petites images associées, telles que les barres d'outils (voir le point "Réduire les demandes HTTP").
• Utilisez les images-objets d'image SVG pour les petites images associées, telles que les barres d'outils. La coloration SVG est un peu délicate. Vous pouvez lire à ce sujet ici .
• Les sites Web occupés doivent envisager de scinder les composants entre les domaines . Plus précisément...
• Le contenu statique (images, CSS, JavaScript et, en règle générale, le contenu ne nécessitant pas l'accès aux cookies) doit être placé dans un domaine distinct qui n'utilise pas de cookies , car tous les cookies d'un domaine et de ses sous-domaines sont envoyés avec chaque demande envoyée au destinataire. domaine et ses sous-domaines. Une bonne option consiste à utiliser un réseau de distribution de contenu (CDN), mais considérons le cas où ce dernier peut échouer en incluant des CDN alternatifs ou des copies locales pouvant être servies à la place.
• Réduisez le nombre total de requêtes HTTP requises pour qu'un navigateur rende la page.
• Choisissez un moteur de template et rendez-le / pré-compilez en utilisant des tâches telles que gulp ou grunt
• Assurez-vous qu'il y a un favicon.icofichier à la racine du site, c'est-à-dire /favicon.ico. Les navigateurs le demanderont automatiquement , même si l'icône n'est pas mentionnée dans le code HTML. Si vous n'en avez pas /favicon.ico, cela entraînera un grand nombre de 404, épuisant la bande passante de votre serveur.

SEO (Search Engine Optimization)

• Utiliser des URL "conviviales pour les moteurs de recherche", c’est-à-dire utiliser example.com/pages/45-article-titleau lieu deexample.com/index.php?page=45
• Lors de l' utilisation #du contenu dynamique changer #à #!et sur le serveur $_REQUEST["_escaped_fragment_"]est ce que Googlebot utilise au lieu de #!. En d'autres termes, ./#!page=1devient ./?_escaped_fragments_=page=1. En outre, pour les utilisateurs pouvant utiliser FF.b4 ou Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");C’est une excellente commande. Ainsi, même si la barre d'adresse a changé, la page ne se recharge pas. Cela vous permet d'utiliser ?au lieu de #!conserver du contenu dynamique et d'indiquer également au serveur lorsque vous envoyez le lien par courrier électronique que nous sommes après cette page, et AJAX n'a ​​pas besoin de faire une autre demande supplémentaire.
• N'utilisez pas de liens disant "cliquez ici" . Vous gaspillez une opportunité de référencement et cela complique les choses pour les lecteurs d’écran.
• Avoir un sitemap XML , de préférence à l'emplacement par défaut /sitemap.xml.
• À utiliser <link rel="canonical" ... />lorsque plusieurs URL pointent vers le même contenu. Ce problème peut également être résolu à partir des outils pour les webmasters de Google .
• Utilisez Google Webmaster Tools et Bing Webmaster Tools .
• Installez Google Analytics dès le début (ou un outil d’analyse open source tel que Piwik ).
• Savoir comment robots.txt et les moteurs de recherche fonctionnent.
• Rediriger les demandes (en utilisant 301 Moved Permanently) en demandant www.example.comà example.com(ou l'inverse) pour empêcher la division du classement Google sur les deux sites.
• Sachez qu'il peut y avoir des araignées mal élevées.
• Si vous avez un contenu non textuel, examinez les extensions de sitemap de Google pour la vidéo, etc. Il existe de bonnes informations à ce sujet dans la réponse de Tim Farley .

La technologie

• Comprenez HTTP et des choses comme GET, POST, des sessions, des cookies et ce que signifie être "sans état".
• Ecrivez votre XHTML / HTML et CSS conformément aux spécifications du W3C et assurez-vous qu'ils sont validés . Le but ici est d’éviter les modes bizarreries de navigateur et, en prime, de faciliter le travail avec des navigateurs non traditionnels tels que les lecteurs d’écran et les appareils mobiles.
• Comprendre comment JavaScript est traité dans le navigateur.
• Comprenez comment JavaScript, les feuilles de style et les autres ressources utilisées par votre page sont chargés et considérez leur impact sur les performances perçues . Il est maintenant largement considéré comme approprié de déplacer les scripts vers le bas de vos pages, les exceptions étant généralement des applications telles que des applications d'analyse ou des schémas HTML5.
• Comprenez comment fonctionne le sandbox JavaScript, en particulier si vous avez l'intention d'utiliser des iframes.
• Sachez que JavaScript peut et sera désactivé, et qu'AJAX est donc une extension et non une base. Même si la plupart des utilisateurs normaux le laissent maintenant, rappelez-vous que NoScript devient de plus en plus populaire, que les appareils mobiles risquent de ne pas fonctionner comme prévu et que Google n'exécutera pas la majeure partie de votre JavaScript lors de l'indexation du site.
• Découvrez la différence entre les redirections 301 et 302 (il s'agit également d'un problème de référencement).
• Apprenez le plus possible sur votre plateforme de déploiement.
• Pensez à utiliser une feuille de style de réinitialisation ou normalize.css .
• Pensez aux frameworks JavaScript (tels que jQuery , MooTools , Prototype , Dojo ou YUI 3 ), qui masqueront de nombreuses différences entre les navigateurs lors de l’utilisation de JavaScript pour la manipulation DOM.
• Si vous combinez performances perçues et infrastructures JS, envisagez d'utiliser un service tel que l' API Google Libraries pour charger les infrastructures de sorte qu'un navigateur puisse utiliser une copie de l'infrastructure déjà mise en cache au lieu de télécharger une copie dupliquée à partir de votre site.
• Ne réinventez pas la roue. Avant toute chose, recherchez un composant ou un exemple sur la façon de le faire. Il y a 99% de chances que quelqu'un l'ait fait et ait publié une version SSS du code.
• À l'inverse, ne commencez pas par 20 bibliothèques avant même d'avoir déterminé quels sont vos besoins. Particulièrement sur le Web côté client où il est presque toujours plus important de garder la légèreté, la rapidité et la flexibilité.

Correction de bugs

• Comprenez que vous passerez 20% de votre temps à coder et à 80% à le maintenir, donc codez en conséquence.
• Configurez une bonne solution de rapport d'erreur.
• Ayez un système pour que les gens vous contactent avec des suggestions et des critiques.
• Documentez le fonctionnement de l'application pour le futur personnel de support et les personnes effectuant la maintenance.
• Faites des sauvegardes fréquentes! (Et assurez-vous que ces sauvegardes sont fonctionnelles) Ayez une stratégie de restauration, pas seulement une stratégie de sauvegarde.
• Utilisez un système de contrôle de version pour stocker vos fichiers, tels que Subversion , Mercurial ou Git .
• N'oubliez pas de faire vos tests d'acceptation. Des cadres comme Selenium peuvent aider. Surtout si vous automatisez complètement vos tests, peut-être en utilisant un outil d'intégration continue, tel que Jenkins .
• Assurez-vous que la journalisation est suffisante en utilisant des infrastructures telles que log4j , log4net ou log4r . Si quelque chose ne va pas sur votre site en direct, vous aurez besoin d'un moyen de savoir quoi.
• Lors de la journalisation, assurez-vous de capturer les exceptions gérées et les exceptions non gérées. Rapportez / analysez la sortie du journal, car elle vous indiquera où se trouvent les principaux problèmes de votre site.

Autre

• Implémentez la surveillance et l'analyse côté serveur et côté client (l'une doit être proactive plutôt que réactive).
• Utilisez des services tels que UserVoice et Intercom (ou tout autre outil similaire) pour rester en contact permanent avec vos utilisateurs.
• Suivez Vincent Driessen du modèle de branchement Git

Beaucoup de choses ont été omises, pas nécessairement parce qu'elles ne sont pas des réponses utiles, mais parce qu'elles sont trop détaillées, hors du champ d'application ou vont un peu trop loin pour quiconque cherche à avoir un aperçu de ce qu'il devrait savoir. N'hésitez pas à éditer ça aussi, j'ai probablement manqué des choses ou fait des erreurs.