¿Qué detalles técnicos debe considerar un programador de una aplicación web antes de hacer público el sitio?

¿Qué cosas debe considerar un programador que implementa los detalles técnicos de una aplicación web antes de hacer público el sitio? Si Jeff Atwood puede olvidarse de HttpOnly galletas , mapas de sitio , y las peticiones falsas de cross-site todos en el mismo sitio , lo que lo importante podría estar olvidando así?

Estoy pensando en esto desde la perspectiva de un desarrollador web, de modo que alguien más esté creando el diseño y el contenido real del sitio. Entonces, aunque la usabilidad y el contenido pueden ser más importantes que la plataforma, usted, el programador, tiene poco que decir al respecto. De lo que debe preocuparse es de que su implementación de la plataforma es estable, funciona bien, es segura y cumple con cualquier otro objetivo comercial (como no costar demasiado, demorar demasiado en construir y clasificar tan bien con Google como contenido compatible).

Piense en esto desde la perspectiva de un desarrollador que ha hecho un trabajo para aplicaciones de tipo intranet en un entorno bastante confiable, y está a punto de tener su primera oportunidad y lanzar un sitio potencialmente popular para toda la gran red mundial.

Además, estoy buscando algo más específico que una respuesta vaga de "estándares web". Quiero decir, HTML, JavaScript y CSS sobre HTTP son casi un hecho, especialmente cuando ya he especificado que eres un desarrollador web profesional. Entonces, yendo más allá de eso, ¿qué estándares? ¿En qué circunstancias y por qué? Proporcione un enlace a la especificación del estándar.

La idea aquí es que la mayoría de nosotros ya debería saber la mayoría de lo que está en esta lista. Pero es posible que haya uno o dos elementos que realmente no haya examinado antes, que no comprenda completamente o que tal vez nunca haya escuchado.

Interfaz y experiencia del usuario

• Tenga en cuenta que los navegadores implementan estándares de manera inconsistente y asegúrese de que su sitio funcione razonablemente bien en todos los navegadores principales. En una prueba mínima contra un motor Gecko reciente ( Firefox ), un motor WebKit ( Safari y algunos navegadores móviles), Chrome , sus navegadores IE compatibles (aproveche las imágenes VPC de compatibilidad de aplicaciones ) y Opera . También considere cómo los navegadores representan su sitio en diferentes sistemas operativos.
• Considere cómo las personas podrían usar el sitio además de los principales navegadores: teléfonos celulares, lectores de pantalla y motores de búsqueda, por ejemplo. - Alguna información de accesibilidad: WAI y Section508 , Desarrollo móvil: MobiForge .
• Puesta en escena: cómo implementar actualizaciones sin afectar a sus usuarios. Tenga uno o más entornos de prueba o de ensayo disponibles para implementar cambios en la arquitectura, el código o el contenido general y asegurarse de que se puedan implementar de forma controlada sin romper nada. Tenga una forma automatizada de implementar cambios aprobados en el sitio en vivo. Esto se implementa de manera más efectiva junto con el uso de un sistema de control de versiones (git, Subversion, etc.) y un mecanismo de construcción automatizado (Ant, NAnt, etc.).
• No muestre errores hostiles directamente al usuario.
• No ponga las direcciones de correo electrónico de los usuarios en texto sin formato, ya que recibirán correo no deseado hasta la muerte.
• Agregue el atributo rel="nofollow"a los enlaces generados por el usuario para evitar el spam .
• Cree límites bien considerados en su sitio : esto también pertenece a Seguridad.
• Aprende a hacer mejoras progresivas .
• Redireccionar después de una POST si esa POST fue exitosa, para evitar que una actualización se envíe nuevamente.
• No olvides tener en cuenta la accesibilidad. Siempre es una buena idea y, en determinadas circunstancias, es un requisito legal . WAI-ARIA y WCAG 2 son buenos recursos en esta área.
• Lee No me hagas pensar .

Seguridad

• Es mucho para digerir, pero la guía de desarrollo de OWASP cubre la seguridad del sitio web de arriba a abajo.
• Conozca la inyección, especialmente la inyección SQL y cómo prevenirla.
• Nunca confíe en la entrada del usuario, ni en ninguna otra cosa que venga en la solicitud (que incluye cookies y valores de campo de formulario ocultos).
• Hash contraseñas con sal y usar diferentes sales para sus filas para evitar ataques de arco iris. Use un algoritmo de hash lento, como bcrypt (probado en el tiempo) o scrypt (aún más fuerte, pero más nuevo) ( 1 , 2 ), para almacenar contraseñas. ( Cómo almacenar de forma segura una contraseña ). El NIST también aprueba PBKDF2 para contraseñas hash ", y está aprobado por FIPS en .NET (más información aquí ). Evite usar directamente la familia MD5 o SHA.
• No intente crear su propio sistema de autenticación elegante . Es muy fácil equivocarse de manera sutil e incontestable y ni siquiera lo sabrías hasta después de ser hackeado.
• Conozca las reglas para procesar tarjetas de crédito . ( Ver esta pregunta también )
• Use SSL / TLS / HTTPS para cualquier sitio donde se ingresen datos confidenciales (como credenciales, información de identificación personal, información de tarjeta de crédito). Let's Encrypt es una autoridad de certificación gratuita que puede ayudar.
• Prevenir el secuestro de sesión .
• Evite las secuencias de comandos de sitios cruzados (XSS).
• Evite las falsificaciones de solicitudes entre sitios (CSRF).
• Evita el clickjacking .
• Mantenga sus sistemas actualizados con los últimos parches.
• Asegúrese de que la información de conexión de su base de datos esté segura.
• Manténgase informado sobre las últimas técnicas de ataque y vulnerabilidades que afectan a su plataforma.
• Lea el Manual de seguridad del navegador Google .
• Lea el Manual del hacker de aplicaciones web .
• Considere el principio del menor privilegio . Intente ejecutar su servidor de aplicaciones como no root . ( ejemplo de tomcat )
• Coloque rel="noopener noreferrer"todos los enlaces proporcionados por el usuario target="_blank"para evitar que JavaScript en la página de destino redirija su página a otro lugar, como una página de inicio de sesión falsa. Más información
• Considere usar una Política de seguridad de contenido estricta .

Actuación

• Implemente el almacenamiento en caché si es necesario, comprenda y use el almacenamiento en caché HTTP correctamente, así como el Manifiesto HTML5 .
• Optimice las imágenes: no utilice una imagen de 20 KB para un fondo repetitivo.
• Comprima el contenido para la velocidad, vea brotli , gzip / deflate ( desinflar es mejor ).
• Combine / concatene múltiples hojas de estilo o múltiples archivos de script para reducir la cantidad de conexiones del navegador y mejorar la capacidad de gzip para comprimir duplicaciones entre archivos.
• Eche un vistazo al sitio Yahoo Exceptional Performance , muchas pautas excelentes, incluida la mejora del rendimiento front-end y su herramienta YSlow (requiere Firefox, Safari, Chrome u Opera). Además, la velocidad de la página de Google (usar con la extensión del navegador ) es otra herramienta para la creación de perfiles de rendimiento, y también optimiza sus imágenes.
• Utilice CSS Image Sprites para pequeñas imágenes relacionadas, como barras de herramientas (consulte el punto "minimizar las solicitudes HTTP")
• Use sprites de imagen SVG para pequeñas imágenes relacionadas, como barras de herramientas. La coloración SVG es un poco complicada. Puedes leer sobre esto aquí .
• Los sitios web ocupados deberían considerar dividir los componentes entre dominios . Específicamente...
• El contenido estático (es decir, imágenes, CSS, JavaScript y, en general, contenido que no necesita acceso a cookies) debe ir en un dominio separado que no use cookies , porque todas las cookies de un dominio y sus subdominios se envían con cada solicitud al dominio y sus subdominios. Una buena opción aquí es usar una Red de entrega de contenido (CDN), pero considere el caso en que esa CDN puede fallar al incluir CDN alternativas o copias locales que se pueden servir en su lugar.
• Minimice el número total de solicitudes HTTP necesarias para que un navegador represente la página.
• Elija un motor de plantillas y renderice / precompile usando corredores de tareas como gulp o gruñido
• Asegúrese de que haya un favicon.icoarchivo en la raíz del sitio, es decir /favicon.ico. Los navegadores lo solicitarán automáticamente , incluso si el icono no se menciona en el HTML. Si no tiene uno /favicon.ico, esto generará muchos 404, agotando el ancho de banda de su servidor.

SEO (optimización de motores de búsqueda)

• Utilice URL "amigables para motores de búsqueda", es decir, use en example.com/pages/45-article-titlelugar deexample.com/index.php?page=45
• Cuando se usa #para contenido dinámico, cambie #a #!ay luego en el servidor $_REQUEST["_escaped_fragment_"]es lo que usa googlebot en lugar de #!. En otras palabras, se ./#!page=1convierte ./?_escaped_fragments_=page=1. Además, para los usuarios que pueden estar usando FF.b4 o Chromium, history.pushState({"foo":"bar"}, "About", "./?page=1");es un gran comando. Entonces, aunque la barra de direcciones ha cambiado, la página no se vuelve a cargar. Esto le permite usar en ?lugar de #!mantener contenido dinámico y también decirle al servidor cuando envía por correo electrónico el enlace que estamos después de esta página, y el AJAX no necesita hacer otra solicitud adicional.
• No use enlaces que digan "haga clic aquí" . Estás desperdiciando una oportunidad de SEO y eso dificulta las cosas para las personas con lectores de pantalla.
• Tener un mapa del sitio XML , preferiblemente en la ubicación predeterminada /sitemap.xml.
• Úselo <link rel="canonical" ... />cuando tenga varias URL que apuntan al mismo contenido, este problema también se puede solucionar desde las Herramientas para webmasters de Google .
• Use las Herramientas para webmasters de Google y las Herramientas para webmasters de Bing .
• Instale Google Analytics desde el principio (o una herramienta de análisis de código abierto como Piwik ).
• Sepa cómo funcionan los robots robots.txt y las arañas de los motores de búsqueda.
• Redirigir las peticiones (usando 301 Moved Permanently) pidiendo www.example.coma example.com(o al revés) para evitar que se resquebraje el ranking de Google entre ambos sitios.
• Sepa que puede haber arañas mal portadas por ahí.
• Si tiene contenido que no es de texto, busque en las extensiones de mapa de sitio de Google para videos, etc. Hay una buena información al respecto en la respuesta de Tim Farley .

Tecnología

• Comprenda HTTP y cosas como GET, POST, sesiones, cookies y lo que significa estar "sin estado".
• Escriba su XHTML / HTML y CSS de acuerdo con las especificaciones W3C y asegúrese de que validen . El objetivo aquí es evitar los modos de peculiaridades del navegador y, como beneficio adicional, es mucho más fácil trabajar con navegadores no tradicionales como lectores de pantalla y dispositivos móviles.
• Comprenda cómo se procesa JavaScript en el navegador.
• Comprenda cómo se cargan JavaScript, las hojas de estilo y otros recursos utilizados por su página y considere su impacto en el rendimiento percibido . Ahora se considera ampliamente apropiado mover los scripts al final de sus páginas, con excepciones que generalmente son cosas como aplicaciones de análisis o cuñas HTML5.
• Comprenda cómo funciona el entorno limitado de JavaScript, especialmente si tiene la intención de usar iframes.
• Tenga en cuenta que JavaScript puede y estará deshabilitado, y que AJAX es, por lo tanto, una extensión, no una línea de base. Incluso si la mayoría de los usuarios normales lo dejan encendido ahora, recuerde que NoScript se está volviendo más popular, los dispositivos móviles pueden no funcionar como se espera y Google no ejecutará la mayor parte de su JavaScript al indexar el sitio.
• Conozca la diferencia entre los redireccionamientos 301 y 302 (esto también es un problema de SEO).
• Aprenda todo lo que pueda sobre su plataforma de implementación.
• Considere usar una Hoja de estilo de reinicio o normalize.css .
• Considere los marcos de JavaScript (como jQuery , MooTools , Prototype , Dojo o YUI 3 ), que ocultarán muchas de las diferencias del navegador al usar JavaScript para la manipulación DOM.
• Tomando el rendimiento percibido y los marcos JS juntos, considere usar un servicio como el API de Google Libraries para cargar marcos para que un navegador pueda usar una copia del marco que ya ha almacenado en caché en lugar de descargar una copia duplicada de su sitio.
• No reinventes la rueda. Antes de hacer NADA, busque un componente o ejemplo sobre cómo hacerlo. Hay un 99% de posibilidades de que alguien lo haya hecho y haya lanzado una versión OSS del código.
• Por otro lado, no comience con 20 bibliotecas antes de que haya decidido cuáles son sus necesidades. Particularmente en la web del lado del cliente, donde casi siempre es más importante mantener las cosas livianas, rápidas y flexibles.

Corrección de errores

• Comprenda que pasará el 20% de su tiempo codificando y el 80% manteniendo, así que codifique en consecuencia.
• Configure una buena solución de informe de errores.
• Tenga un sistema para que las personas lo contacten con sugerencias y críticas.
• Documente cómo funciona la aplicación para el personal de soporte futuro y las personas que realizan el mantenimiento.
• ¡Haz copias de seguridad frecuentes! (Y asegúrese de que esas copias de seguridad sean funcionales) Tenga una estrategia de restauración, no solo una estrategia de copia de seguridad.
• Use un sistema de control de versiones para almacenar sus archivos, como Subversion , Mercurial o Git .
• No olvide hacer su Prueba de aceptación. Los marcos como Selenium pueden ayudar. Especialmente si automatiza completamente sus pruebas, tal vez mediante el uso de una herramienta de integración continua, como Jenkins .
• Asegúrese de tener un registro suficiente en su lugar utilizando marcos como log4j , log4net o log4r . Si algo sale mal en su sitio en vivo, necesitará una forma de averiguar qué.
• Al iniciar sesión, asegúrese de capturar tanto las excepciones manejadas como las no manejadas. Informe / analice el resultado del registro, ya que le mostrará dónde están los problemas clave en su sitio.

Otro

• Implemente monitoreo y análisis del lado del servidor y del lado del cliente (uno debe ser proactivo en lugar de reactivo).
• Use servicios como UserVoice e Intercom (o cualquier otra herramienta similar) para mantenerse constantemente en contacto con sus usuarios.
• Siga Vicente Driessen 's modelo de ramificación Git

Se omiten muchas cosas no necesariamente porque no son respuestas útiles, sino porque son demasiado detalladas, están fuera de alcance o van demasiado lejos para alguien que busca obtener una visión general de las cosas que deberían saber. Por favor, siéntase libre de editar esto también, probablemente me perdí algunas cosas o cometí algunos errores.