Quais detalhes técnicos o programador de um aplicativo da web deve considerar antes de tornar o site público?

O que um programador que implementa os detalhes técnicos de um aplicativo Web deve considerar antes de tornar o site público? Se Jeff Atwood pode esquecer cookies HttpOnly , sitemaps , e cross-site request falsificações todos no mesmo local , o que importante eu poderia estar esquecendo também?

Estou pensando nisso da perspectiva de um desenvolvedor da Web, para que outra pessoa esteja criando o design e o conteúdo reais do site. Portanto, embora a usabilidade e o conteúdo possam ser mais importantes que a plataforma, você, o programador, tem pouco a dizer sobre isso. O que você precisa se preocupar é que sua implementação da plataforma seja estável, tenha bom desempenho, seja segura e atenda a quaisquer outras metas de negócios (como não custar muito, demorar muito para construir e classificar tão bem quanto o Google como o suporte de conteúdo).

Pense nisso da perspectiva de um desenvolvedor que fez algum trabalho para aplicativos do tipo intranet em um ambiente bastante confiável e está prestes a ter sua primeira chance e lançar um site potencialmente popular para toda a grande e ruim rede mundial de computadores.

Além disso, estou procurando algo mais específico do que apenas uma resposta vaga de "padrões da web". Quero dizer, HTML, JavaScript e CSS sobre HTTP são praticamente um dado, especialmente quando eu já especifiquei que você é um desenvolvedor web profissional. Então, indo além disso, quais padrões? Em que circunstâncias e por quê? Forneça um link para a especificação do padrão.

A idéia aqui é que a maioria de nós já deve saber a maior parte do que está nesta lista. Mas pode haver apenas um ou dois itens que você realmente não analisou antes, que não entende completamente, ou talvez nunca tenha ouvido falar.

Interface e experiência do usuário

• Esteja ciente de que os navegadores implementam os padrões de maneira inconsistente e verifique se o site funciona razoavelmente bem em todos os principais navegadores. Em um teste mínimo em relação a um mecanismo recente Gecko ( Firefox ), um mecanismo WebKit ( Safari e alguns navegadores móveis), Chrome , seus navegadores IE suportados (aproveite as Imagens VPC de compatibilidade de aplicativos ) e Opera . Considere também como os navegadores renderizam seu site em diferentes sistemas operacionais.
• Considere como as pessoas podem usar o site que não seja dos principais navegadores: telefones celulares, leitores de tela e mecanismos de pesquisa, por exemplo. - Algumas informações de acessibilidade: WAI e Section508 , Desenvolvimento móvel: MobiForge .
• Preparo: Como implantar atualizações sem afetar seus usuários. Tenha um ou mais ambientes de teste ou armazenamento temporário disponíveis para implementar alterações na arquitetura, no código ou no conteúdo abrangente e garantir que eles possam ser implantados de maneira controlada sem quebrar nada. Tenha uma maneira automatizada de implantar alterações aprovadas no site ativo. Isso é implementado de maneira mais eficaz em conjunto com o uso de um sistema de controle de versão (git, Subversion, etc.) e um mecanismo de compilação automatizado (Ant, NAnt, etc.).
• Não exiba erros hostis diretamente para o usuário.
• Não coloque os endereços de email dos usuários em texto sem formatação, pois eles receberão spam até a morte.
• Adicione o atributo rel="nofollow"aos links gerados pelo usuário para evitar spam .
• Crie limites bem considerados no seu site - isso também pertence a Segurança.
• Aprenda a fazer aprimoramento progressivo .
• Redirecione após um POST se esse POST foi bem-sucedido, para impedir que uma atualização seja enviada novamente.
• Não se esqueça de levar em consideração a acessibilidade. É sempre uma boa ideia e, em certas circunstâncias, é um requisito legal . WAI-ARIA e WCAG 2 são bons recursos nessa área.
• Leia Não me faça pensar .

Segurança

• É muito digerível, mas o guia de desenvolvimento da OWASP cobre a segurança do site de cima para baixo.
• Conheça a injeção, especialmente a injeção SQL, e como evitá-la.
• Nunca confie na entrada do usuário, nem em qualquer outra coisa que esteja presente na solicitação (que inclui cookies e valores de campos de formulário ocultos!).
• Hash senhas usando sal e use sais diferentes para suas linhas para evitar ataques do arco-íris. Use um algoritmo de hash lento, como bcrypt (tempo testado) ou scrypt (ainda mais forte, mas mais recente) ( 1 , 2 ), para armazenar senhas. ( Como armazenar com segurança uma senha ). O NIST também aprova o PBKDF2 para senhas de hash "e é aprovado pelo FIPS no .NET (mais informações aqui ). Evite usar a família MD5 ou SHA diretamente.
• Não tente criar seu próprio sistema de autenticação sofisticado . É uma coisa tão fácil cometer erros de maneiras sutis e não testáveis ​​e você nem sabia disso até depois de ser hackeado.
• Conheça as regras para o processamento de cartões de crédito . ( Veja esta pergunta também )
• Use SSL / TLS / HTTPS para qualquer site em que dados confidenciais sejam inseridos (como credenciais, informações de identificação pessoal, informações de cartão de crédito). Let's Encrypt é uma autoridade de certificação gratuita que pode ajudar.
• Impedir o seqüestro de sessão .
• Evite scripts entre sites (XSS).
• Evite falsificações de solicitação entre sites (CSRF).
• Evite Clickjacking .
• Mantenha seu (s) sistema (s) atualizado (s) com as últimas correções.
• Verifique se as informações de conexão do banco de dados estão protegidas.
• Mantenha-se informado sobre as mais recentes técnicas de ataque e vulnerabilidades que afetam sua plataforma.
• Leia o Manual de segurança do navegador Google .
• Leia o Manual do hacker de aplicativos da Web .
• Considere o princípio do menor privilégio . Tente executar o servidor de aplicativos como não raiz . ( exemplo do tomcat )
• Coloque rel="noopener noreferrer"todos os links fornecidos pelo usuário target="_blank"para impedir que o JavaScript na página de destino redirecione sua página para outro lugar, como uma página de login falsa. Mais informações
• Considere usar uma Política de Segurança de Conteúdo estrita .

atuação

• Implemente o cache, se necessário, entenda e use o cache HTTP corretamente, bem como o Manifesto HTML5 .
• Otimizar imagens - não use uma imagem de 20 KB para um fundo repetitivo.
• Comprima o conteúdo para velocidade, veja brotli , gzip / deflate ( desinflar é melhor ).
• Combine / concatene várias folhas de estilo ou vários arquivos de script para reduzir o número de conexões do navegador e melhorar a capacidade do gzip para compactar duplicações entre arquivos.
• Dê uma olhada no site Yahoo Exceptional Performance , com muitas ótimas diretrizes, incluindo a melhoria do desempenho do front-end e sua ferramenta YSlow (requer Firefox, Safari, Chrome ou Opera). Além disso, a velocidade da página do Google (usada com a extensão do navegador ) é outra ferramenta para criação de perfil de desempenho e otimiza suas imagens também.
• Use Sprites de imagem CSS para pequenas imagens relacionadas, como barras de ferramentas (consulte o ponto "minimizar solicitações HTTP")
• Use sprites de imagem SVG para pequenas imagens relacionadas, como barras de ferramentas. A coloração SVG é um pouco complicada. Você pode ler sobre isso aqui .
• Sites ocupados devem considerar a divisão de componentes entre domínios . Especificamente...
• O conteúdo estático (por exemplo, imagens, CSS, JavaScript e, geralmente, conteúdo que não precisa de acesso a cookies) deve ir em um domínio separado que não use cookies , porque todos os cookies de um domínio e seus subdomínios são enviados com todas as solicitações ao domínio e seus subdomínios. Uma boa opção aqui é usar uma rede de entrega de conteúdo (CDN), mas considere o caso em que essa CDN pode falhar, incluindo CDNs alternativas ou cópias locais que podem ser veiculadas.
• Minimize o número total de solicitações HTTP necessárias para um navegador renderizar a página.
• Escolha um mecanismo de modelo e renderize / pré-compile-o usando executores de tarefas como gulp ou grunt
• Verifique se há um favicon.icoarquivo na raiz do site, ou seja /favicon.ico. Os navegadores solicitarão automaticamente , mesmo que o ícone não seja mencionado no HTML. Se você não tiver um /favicon.ico, isso resultará em muitos 404s, esgotando a largura de banda do servidor.

SEO (Otimização de sites)

• Use URLs "compatíveis com mecanismos de pesquisa", ou seja, use em example.com/pages/45-article-titlevez deexample.com/index.php?page=45
• Ao usar #para conteúdo dinâmico, altere #para #!e no servidor $_REQUEST["_escaped_fragment_"]é o que o googlebot usa em vez de #!. Em outras palavras, ./#!page=1torna-se ./?_escaped_fragments_=page=1. Além disso, para usuários que podem estar usando o FF.b4 ou o Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");é um ótimo comando. Portanto, mesmo que a barra de endereço tenha mudado, a página não é recarregada. Isso permite que você use, em ?vez de #!manter, conteúdo dinâmico e também informe ao servidor quando enviar um email para o link que estamos após esta página, e o AJAX não precisa fazer outra solicitação extra.
• Não use links que digam "clique aqui" . Você está desperdiçando uma oportunidade de SEO e isso torna as coisas mais difíceis para as pessoas com leitores de tela.
• Tenha um sitemap XML , de preferência no local padrão /sitemap.xml.
• Use <link rel="canonical" ... />quando você tiver vários URLs que apontam para o mesmo conteúdo, esse problema também pode ser solucionado nas Ferramentas do Google para webmasters .
• Use as Ferramentas para webmasters do Google e as Ferramentas para webmasters do Bing .
• Instale o Google Analytics desde o início (ou uma ferramenta de análise de código aberto como o Piwik ).
• Saiba como o robots.txt e as aranhas dos mecanismos de pesquisa funcionam.
• Redirecionar solicitações (usando 301 Moved Permanently) pedindo www.example.compara example.com(ou o contrário) para evitar dividir o ranking google entre os dois sites.
• Saiba que pode haver aranhas mal comportadas por aí.
• Se você tiver conteúdo não textual, procure as extensões de mapa do site do Google para vídeos, etc. Há uma boa informação sobre isso na resposta de Tim Farley .

Tecnologia

• Entenda HTTP e coisas como GET, POST, sessões, cookies e o que significa ser "sem estado".
• Escreva seu XHTML / HTML e CSS de acordo com as especificações do W3C e verifique se eles são validados . O objetivo aqui é evitar os modos peculiares do navegador e, como bônus, facilitar o trabalho com navegadores não tradicionais, como leitores de tela e dispositivos móveis.
• Entenda como o JavaScript é processado no navegador.
• Entenda como o JavaScript, as folhas de estilo e outros recursos usados ​​por sua página são carregados e considere seu impacto no desempenho percebido . Agora, é amplamente considerado apropriado mover scripts para o final de suas páginas, com exceções que normalmente são coisas como aplicativos de análise ou shims HTML5.
• Entenda como a sandbox JavaScript funciona, especialmente se você pretende usar iframes.
• Esteja ciente de que o JavaScript pode e será desativado e que o AJAX é, portanto, uma extensão, não uma linha de base. Mesmo que a maioria dos usuários normais o deixe ligado agora, lembre-se de que o NoScript está se tornando mais popular, os dispositivos móveis podem não funcionar conforme o esperado e o Google não executa a maior parte do seu JavaScript ao indexar o site.
• Saiba a diferença entre os redirecionamentos 301 e 302 (esse também é um problema de SEO).
• Aprenda o máximo possível sobre sua plataforma de implantação.
• Considere usar uma Redefinir folha de estilos ou normalize.css .
• Considere as estruturas JavaScript (como jQuery , MooTools , Prototype , Dojo ou YUI 3 ), que ocultarão muitas diferenças do navegador ao usar JavaScript para manipulação de DOM.
• Reunindo o desempenho percebido e as estruturas JS, considere usar um serviço como a API de bibliotecas do Google para carregar estruturas, para que um navegador possa usar uma cópia da estrutura que ele já armazenou em cache, em vez de fazer o download de uma cópia duplicada do seu site.
• Não reinvente a roda. Antes de fazer QUALQUER COISA, procure um componente ou exemplo de como fazê-lo. Há 99% de chance de alguém ter feito isso e lançado uma versão OSS do código.
• Por outro lado, não comece com 20 bibliotecas antes mesmo de decidir quais são suas necessidades. Particularmente na Web do lado do cliente, onde quase sempre é mais importante manter as coisas leves, rápidas e flexíveis.

Corrigindo erro

• Entenda que você gastará 20% do seu tempo codificando e 80% dele mantendo, portanto, codifique de acordo.
• Configure uma boa solução de relatório de erros.
• Tenha um sistema para as pessoas entrarem em contato com você com sugestões e críticas.
• Documente como o aplicativo funciona para futuras equipes de suporte e pessoas que realizam manutenção.
• Faça backups frequentes! (E verifique se esses backups estão funcionais) Tenha uma estratégia de restauração, não apenas uma estratégia de backup.
• Use um sistema de controle de versão para armazenar seus arquivos, como Subversion , Mercurial ou Git .
• Não se esqueça de fazer seu teste de aceitação. Estruturas como o Selenium podem ajudar. Especialmente se você automatizar totalmente seus testes, talvez usando uma ferramenta de Integração Contínua, como o Jenkins .
• Verifique se você possui log suficiente usando estruturas como log4j , log4net ou log4r . Se algo der errado no seu site ao vivo, você precisará descobrir como.
• Ao fazer o log, certifique-se de capturar as exceções tratadas e não tratadas. Relate / analise a saída do log, pois ela mostra onde estão os principais problemas do seu site.

De outros

• Implemente monitoramento e análise do lado do servidor e do cliente (um deve ser proativo em vez de reativo).
• Use serviços como UserVoice e Intercom (ou qualquer outra ferramenta similar) para manter contato constante com seus usuários.
• Siga Vincent Driessen 's Git modelo de ramificação

Muitas coisas foram omitidas não necessariamente porque não são respostas úteis, mas porque são muito detalhadas, estão fora do escopo ou vão um pouco longe demais para alguém que deseja ter uma visão geral do que deve saber. Sinta-se à vontade para editar isso também, provavelmente perdi algumas coisas ou cometi alguns erros.