Secure Server Implementation (Cheat Sheet)
Kevin Moreland, Software Engineer
Why would you want to implement a server from scratch? Sure, you could use Spring, Vaadin, Jetty, or one of a hundred other server frameworks and you'll be up and running much faster. Where's the fun in that?
Implementing your own is an excellent way to learn about the underlying protocols and standards. Resist the urge to use any third party libraries, wrappers, or built-in server classes so there is no "magic" hidden from view. This is by no means an exhaustive list:
- Make a build script (test locally, backup, deploy)
- Before getting too deep in code or trying to optimize, implement logging of requests/responses and benchmarking of response times
- Start with the HTTP 1.1 spec
- Identify the minimum feature set required
- Support the most common HTTP status codes and provide configurable error pages
- Handle permanent redirects to secure versions (separate server on 80)
- Support 304 not modified response
- Support keep alive and content-length headers
- Run server on a higher port with a limited permission, non-root user
- Skip implementing compression
- Give older clients the finger if you can afford to:
- Do not support older ciphers, non TLS 1.2 connections, or insecure negotiation mechanisms
- Monitor rejected TLS negotiations (just in case you were too restrictive for your target audience)
- Support permanent and temporary redirects
- Visit OWASP for security-minded headers that should be supported
- Redirect for canonicalization (limit dupes in engines)
- Enable SSL session creation, ids
- Set a max connection limit for server socket
- Limit the number of simultaneous connections/keep alive connects a single ip address can hold
- Set a reasonable keep alive time limit
- Limit max bytes on input stream
- Consider dropping speculative Chrome connections
- Implement no-cache headers on sensitive pages, resources, and items that require auth
- Implement the CSP header
- Avoid intensive computations used only during debug
- Disable unnecessary debug logging in production
- Cache expensive processes / static responses
- Limit parsing of dates
- Don't deliver sensitive server type, version, build date, etc. in production
- Don't deliver sensitive information during errors in production
- Submit host to hstspreload.org once stable
- Add a Certification Authority Authorization (CAA) DNS record
Bonus points for:
- Supporting ChaCha20Poly1305 for mobile devices
- Using a 4096 bit server cert. TLS negotiation will take longer, but this can be offset by implementing keep alive, not modified headers, and keeping response sizes reasonable.
- Implementing backup scripts/tools to administer your server
- Implementing a "Maintenance Mode" server while the primary server is being rebuilt/synced
- Implementing a Monitoring/logging system for requests and server errors
- Implementing a watchdog server-side for monitoring and restarting servers
- Implementing multiple types of tripwires for auto-blocking bad actors
- Preventing hotlinking
- Implementing sessions / cookie handling
- Detecting session hijacking and warning the user
- Warning user if secure content is being intercepted with proxy or altered
- Implementing external monitoring of server (uptime, cert fingerprinting, port scanning, benchmarking response times)
- Automating LetsEncrypt cert renewal > into Java keystore; use full chain
- Coding a server implementation that supports the HTTP2 spec
- Supporting TLS 1.3
Web site / Content considerations:
- Design for mobile first, then overrides for desktops
- Ensure your site is responsive
- Use HTML5
- Minimize or eliminate third party resources
- Do not combine secure and non-secure resources if using third parties
- Prevent security issues by visiting OWASP for latest recommendations
- Validate all HTML, CSS, JS, and remove unused cruft
- At a minimum, test in the latest Chrome, Firefox, and Safari releases on all your target platforms
- Use placeholders in DB queries
- Reduce bandwidth by returning minimal HTML, CSS, JS to accomplish goals
- Guard against tree walking attacks
- Guard against accessing non-public resources
- Site icons (apple, android, favicon, ms)
- Set up the Google Search Console for your site
- Google site verification via DNS TXT record
- Humans and robots.txt
- Implement well-known items
- Apple-site-association file
- Validate all client input, including headers and verbs server-side
- Use Rich Snippets
You'll make plenty of mistakes — learn from them. You may be rewarded with less bloat/overhead. Visit OWASP to see if you've missed anything. Run some pen test tools against your server and set achieving an A+ rating from SSL Labs as one of your goals:
Other articles on this web site:
- Why create a design doc? And why you shouldn’t skip it.
The benefits of having a design document before you start coding.
- Why you should design for the mobile browser first.
Make a great first impression by focusing on mobile visitors.
- Designing a Server Monitoring and Alerting Service (Cheat Sheet)
A checklist of items when rolling your own server monitoring service.
- Automating the set up of a Linux-based VPS (Cheat Sheet)
Considerations when configuring a Debian-based Linux VPS.
- Certbot Automation for Java-based Servers (Cheat Sheet)
Ideas on how to automate Letsencrypt's certbot when you are running a Java-based server such as TomCat.
- Automate everything you possibly can, starting with your environment.
Automate everything you possibly can from the very beginning before writing the first line of project code.