Quali dettagli tecnici dovrebbe considerare un programmatore di un'applicazione Web prima di rendere pubblico il sito?

Cosa dovrebbe considerare un programmatore che implementa i dettagli tecnici di un'applicazione Web prima di rendere pubblico il sito? Se Jeff Atwood può dimenticare cookie HttpOnly , sitemap , e cross-site request falsificazioni tutti nello stesso sito , cosa importante cosa che potrei essere dimenticando così?

Ci sto pensando dal punto di vista di uno sviluppatore web, in modo tale che qualcun altro stia creando il design e i contenuti effettivi per il sito. Quindi, mentre l'usabilità e il contenuto possono essere più importanti della piattaforma, voi programmatori avete poco da dire in proposito. Quello di cui devi preoccuparti è che l'implementazione della piattaforma è stabile, funziona bene, è sicura e soddisfa tutti gli altri obiettivi aziendali (come non costare troppo, impiegare troppo tempo a costruire e classificare con Google come il contenuti supportati).

Pensa a questo dal punto di vista di uno sviluppatore che ha lavorato per applicazioni di tipo intranet in un ambiente abbastanza affidabile, e sta per avere il suo primo colpo e pubblicare un sito potenzialmente popolare per l'intero grande mondo del male.

Inoltre, sto cercando qualcosa di più specifico di una vaga risposta "standard web". Voglio dire, HTML, JavaScript e CSS su HTTP sono praticamente un dato di fatto, soprattutto quando ho già specificato che sei uno sviluppatore web professionale. Andando oltre, quali standard? In quali circostanze e perché? Fornire un collegamento alle specifiche dello standard.

L'idea qui è che la maggior parte di noi dovrebbe già sapere la maggior parte di ciò che è in questo elenco. Ma potrebbero esserci solo uno o due elementi che non hai mai esaminato prima, che non capisci completamente o che non hai mai nemmeno sentito parlare.

Interfaccia ed esperienza utente

• Tieni presente che i browser implementano gli standard in modo incoerente e assicurati che il tuo sito funzioni ragionevolmente bene su tutti i principali browser. Con un test minimo contro un recente motore Gecko ( Firefox ), un motore WebKit ( Safari e alcuni browser per dispositivi mobili), Chrome , i browser IE supportati (sfrutta le immagini VPC di compatibilità delle applicazioni ) e Opera . Considera anche come i browser visualizzano il tuo sito in diversi sistemi operativi.
• Considera come le persone potrebbero utilizzare il sito oltre che dai principali browser: telefoni cellulari, screen reader e motori di ricerca, ad esempio. - Alcune informazioni sull'accessibilità: WAI e Section508 , Sviluppo mobile: MobiForge .
• Staging: come distribuire gli aggiornamenti senza influire sugli utenti. Avere uno o più ambienti di test o di gestione temporanea disponibili per implementare modifiche all'architettura, al codice o al contenuto ampio e garantire che possano essere distribuiti in modo controllato senza interrompere nulla. Avere un modo automatico di distribuire le modifiche approvate al sito live. Questo è implementato in modo più efficace in combinazione con l'uso di un sistema di controllo della versione (git, Subversion, ecc.) E un meccanismo di costruzione automatizzato (Ant, NAnt, ecc.).
• Non visualizzare errori ostili direttamente all'utente.
• Non mettere gli indirizzi e-mail degli utenti in chiaro perché verranno spammati a morte.
• Aggiungi l'attributo rel="nofollow"ai link generati dall'utente per evitare lo spam .
• Costruisci limiti ben ponderati nel tuo sito - Anche questo appartiene alla sicurezza.
• Scopri come migliorare progressivamente .
• Reindirizzare dopo un POST se tale POST ha avuto esito positivo, per impedire che un aggiornamento venga inviato nuovamente.
• Non dimenticare di tenere conto dell'accessibilità. È sempre una buona idea e in determinate circostanze è un requisito legale . WAI-ARIA e WCAG 2 sono buone risorse in questo settore.
• Leggi Non farmi pensare .

Sicurezza

• È molto difficile da digerire ma la guida allo sviluppo di OWASP copre la sicurezza del sito Web dall'alto verso il basso.
• Informazioni sull'iniezione, in particolare sull'iniezione SQL e su come prevenirla.
• Non fidarti mai dell'input dell'utente, né di qualsiasi altra cosa che arrivi nella richiesta (che include i cookie e i valori dei campi dei moduli nascosti!).
• Hash password usando il sale e utilizzare sali diversi per le tue file per prevenire attacchi arcobaleno. Utilizzare un algoritmo di hashing lento, come bcrypt (tempo testato) o scrypt (ancora più forte, ma più recente) ( 1 , 2 ), per memorizzare le password. ( Come conservare in modo sicuro una password ). Il NIST approva anche PBKDF2 per le password di hash ", ed è approvato FIPS in .NET (maggiori informazioni qui ). Evitare di utilizzare direttamente la famiglia MD5 o SHA.
• Non provare a inventare il tuo sistema di autenticazione sofisticato . È una cosa così facile sbagliarsi in modi impercettibili e non verificabili e non lo sapresti nemmeno fino a quando non sei stato violato.
• Conoscere le regole per l'elaborazione delle carte di credito . ( Vedi anche questa domanda )
• Utilizzare SSL / TLS / HTTPS per tutti i siti in cui sono inseriti dati sensibili (come credenziali, informazioni di identificazione personale, informazioni sulla carta di credito). Let's Encrypt è un'autorità di certificazione gratuita che può aiutarti.
• Prevenire il dirottamento della sessione .
• Evita gli script tra siti (XSS).
• Evita falsi di richieste tra siti (CSRF).
• Evita il clickjacking .
• Mantieni i tuoi sistemi aggiornati con le ultime patch.
• Assicurarsi che le informazioni sulla connessione al database siano protette.
• Tieniti informato sulle ultime tecniche di attacco e le vulnerabilità che colpiscono la tua piattaforma.
• Leggi il manuale di sicurezza di Google Browser .
• Leggi il manuale di Web Application Hacker .
• Considera il principio del privilegio minimo . Prova a eseguire l'app server come non root . ( esempio Tomcat )
• Inserisci rel="noopener noreferrer"tutti i link forniti dagli utenti con target="_blank"per impedire a JavaScript nella pagina di destinazione di reindirizzare la tua pagina da qualche altra parte, come una pagina di accesso falsa. Ulteriori informazioni
• Prendi in considerazione l'utilizzo di una rigorosa politica di sicurezza dei contenuti .

Prestazione

• Implementare la memorizzazione nella cache, se necessario, comprendere e utilizzare correttamente la memorizzazione nella cache HTTP e manifest HTML5 .
• Ottimizza immagini: non utilizzare un'immagine da 20 KB per uno sfondo ripetuto.
• Comprimi il contenuto per la velocità, vedi brotli , gzip / deflate ( deflate è migliore ).
• Combina / concatena più fogli di stile o più file di script per ridurre il numero di connessioni del browser e migliorare la capacità di gzip di comprimere le duplicazioni tra i file.
• Dai un'occhiata al sito Yahoo sulle prestazioni eccezionali , molte linee guida eccezionali, tra cui il miglioramento delle prestazioni del front-end e il loro strumento YSlow (richiede Firefox, Safari, Chrome o Opera). Inoltre, la velocità della pagina di Google (da utilizzare con l' estensione del browser ) è un altro strumento per la profilazione delle prestazioni e ottimizza anche le tue immagini.
• Usa CSS Image Sprites per piccole immagini correlate come le barre degli strumenti (vedi il punto "minimizza le richieste HTTP")
• Usa gli sprite di immagini SVG per piccole immagini correlate come le barre degli strumenti. La colorazione SVG è un po 'complicata. Puoi leggerlo qui .
• I siti Web occupati dovrebbero considerare la suddivisione dei componenti tra domini . In particolare ...
• Il contenuto statico (ad es. Immagini, CSS, JavaScript e generalmente contenuto che non necessita dell'accesso ai cookie) dovrebbe andare in un dominio separato che non utilizza i cookie , poiché tutti i cookie per un dominio e i suoi sottodomini vengono inviati con ogni richiesta al dominio e i suoi sottodomini. Una buona opzione qui è quella di utilizzare una rete di distribuzione di contenuti (CDN), ma considerare il caso in cui tale CDN potrebbe non riuscire includendo CDN alternative o copie locali che possono essere invece offerte.
• Ridurre al minimo il numero totale di richieste HTTP richieste per un browser per eseguire il rendering della pagina.
• Scegli un motore modello e renderlo / pre-compilalo usando task runner come gulp o grunt
• Assicurati che ci sia un favicon.icofile nella radice del sito, ad es /favicon.ico. I browser lo richiederanno automaticamente , anche se l'icona non è menzionata nell'HTML. Se non si dispone di un /favicon.ico, ciò comporterà un sacco di 404 secondi, svuotando la larghezza di banda del server.

SEO (ottimizzazione per i motori di ricerca)

• Utilizza URL "compatibili con i motori di ricerca", ovvero usa example.com/pages/45-article-titleinvece diexample.com/index.php?page=45
• Quando si utilizza #per il contenuto dinamico, cambiare #in #!e poi sul server $_REQUEST["_escaped_fragment_"]è ciò che utilizza googlebot anziché #!. In altre parole, ./#!page=1diventa ./?_escaped_fragments_=page=1. Inoltre, per gli utenti che potrebbero utilizzare FF.b4 o Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");è un ottimo comando. Quindi, anche se la barra degli indirizzi è cambiata, la pagina non viene ricaricata. Ciò ti consente di utilizzare ?invece di #!mantenere il contenuto dinamico e di informare il server quando invii tramite e-mail il collegamento che stiamo seguendo questa pagina e AJAX non deve effettuare un'altra richiesta aggiuntiva.
• Non utilizzare i collegamenti che dicono "fai clic qui" . Stai sprecando un'opportunità SEO e rende le cose più difficili per le persone con screen reader.
• Avere una Sitemap XML , preferibilmente nella posizione predefinita /sitemap.xml.
• Utilizza <link rel="canonical" ... />quando hai più URL che puntano allo stesso contenuto, questo problema può essere risolto anche dagli Strumenti per i Webmaster di Google .
• Utilizza gli Strumenti per i Webmaster di Google e gli Strumenti per i Webmaster di Bing .
• Installa Google Analytics all'inizio (o uno strumento di analisi open source come Piwik ).
• Scopri come funzionano i ragni robots.txt e dei motori di ricerca.
• Reindirizzare le richieste (utilizzando 301 Moved Permanently) chiedendo www.example.comdi example.com(o viceversa) per evitare di dividere la classifica di Google tra i due siti.
• Sappi che ci possono essere ragni mal educati là fuori.
• Se hai contenuti non testuali, cerca nelle estensioni sitemap di Google per i video, ecc. Ci sono alcune buone informazioni a riguardo nella risposta di Tim Farley .

Tecnologia

• Comprendi HTTP e cose come GET, POST, sessioni, cookie e cosa significa essere "apolidi".
• Scrivi XHTML / HTML e CSS in base alle specifiche del W3C e assicurati che siano valide . L'obiettivo qui è quello di evitare le stranezze del browser e, come bonus, è molto più semplice lavorare con browser non tradizionali come screen reader e dispositivi mobili.
• Comprendi come viene elaborato JavaScript nel browser.
• Scopri come vengono caricati JavaScript, i fogli di stile e altre risorse utilizzate dalla tua pagina e considera il loro impatto sulle prestazioni percepite . Ora è ampiamente considerato appropriato spostare gli script nella parte inferiore delle pagine, con le eccezioni che in genere sono cose come app di analisi o shim HTML5.
• Scopri come funziona la sandbox JavaScript, soprattutto se intendi utilizzare iframe.
• Tieni presente che JavaScript può e sarà disabilitato e che AJAX è quindi un'estensione, non una base. Anche se la maggior parte degli utenti normali lo lascia ora attivo , ricorda che NoScript sta diventando più popolare, i dispositivi mobili potrebbero non funzionare come previsto e Google non eseguirà la maggior parte del tuo JavaScript durante l'indicizzazione del sito.
• Scopri la differenza tra reindirizzamenti 301 e 302 (anche questo è un problema SEO).
• Scopri il più possibile sulla tua piattaforma di distribuzione.
• Prendi in considerazione l'utilizzo di un foglio di stile di ripristino o normalize.css .
• Prendi in considerazione i framework JavaScript (come jQuery , MooTools , Prototype , Dojo o YUI 3 ), che nasconderanno molte differenze del browser quando si utilizza JavaScript per la manipolazione del DOM.
• Mettendo insieme le prestazioni percepite e i framework JS, considera l'utilizzo di un servizio come l' API di Google Libraries per caricare i framework in modo che un browser possa utilizzare una copia del framework che ha già memorizzato nella cache anziché scaricare una copia duplicata dal tuo sito.
• Non reinventare la ruota. Prima di fare QUALCOSA cercare un componente o un esempio su come farlo. C'è una probabilità del 99% che qualcuno l'abbia fatto e abbia rilasciato una versione OSS del codice.
• D'altro canto, non iniziare con 20 librerie prima ancora di aver deciso quali sono le tue esigenze. Soprattutto sul Web lato client dove è quasi sempre più importante mantenere le cose leggere, veloci e flessibili.

Correzione di bug

• Comprendi che spenderai il 20% del tuo tempo nella codifica e l'80% della sua manutenzione, quindi codifica di conseguenza.
• Impostare una buona soluzione per la segnalazione degli errori.
• Avere un sistema con cui le persone possano contattarti per suggerimenti e critiche.
• Documentare come funziona l'applicazione per il personale di supporto futuro e le persone che eseguono la manutenzione.
• Fai backup frequenti! (E assicurati che quei backup siano funzionali) Avere una strategia di ripristino, non solo una strategia di backup.
• Utilizza un sistema di controllo versione per archiviare i tuoi file, come Subversion , Mercurial o Git .
• Non dimenticare di fare il test di accettazione. Strutture come il selenio possono essere d'aiuto. Soprattutto se automatizzi completamente i tuoi test, magari utilizzando uno strumento di integrazione continua, come Jenkins .
• Assicurarsi di disporre di una registrazione sufficiente utilizzando framework come log4j , log4net o log4r . Se qualcosa va storto sul tuo sito live, avrai bisogno di un modo per scoprire cosa.
• Durante la registrazione, assicurarsi di acquisire sia le eccezioni gestite che le eccezioni non gestite. Segnala / analizza l'output del registro, in quanto ti mostrerà dove si trovano i problemi chiave nel tuo sito.

Altro

• Implementare monitoraggio e analisi sia lato server che lato client (si dovrebbe essere proattivi piuttosto che reattivi).
• Utilizza servizi come UserVoice e Intercom (o qualsiasi altro strumento simile) per rimanere costantemente in contatto con i tuoi utenti.
• Seguire Vincent Driessen s' Git modello di ramificazione

Molte cose sono state omesse non necessariamente perché non sono risposte utili, ma perché sono o troppo dettagliate, fuori portata o vanno un po 'troppo lontano per qualcuno che cerca di avere una visione d'insieme delle cose che dovrebbero sapere. Non esitate a modificare anche questo, probabilmente mi sono perso alcune cose o ho fatto degli errori.