Developing a web-security mindset
»Security and lack thereof is almost always a design choice and a business decision.«
Security is an ongoing process throughout your projectʼs lifetime.
Itʼs not an item to tick off in a feature sprint.
Defensive programming 101
Secure input and output handling
What is user input?
- The URL (including path or query parameters)
- HTTP method (GET, POST, PUT, DELETE, …) and headers
- Form values, file uploads
- Cookies, browser storage
- Data exchanged with APIs, Flash, applets, etc.
Validate user input
Data type validation
Range and constraint validation
Business logic validation
Sanitize user input
Remove ASCII control characters, null bytes, Unicode LTR/RTL
control characters, Unicode whitespace, …
- (Usually) remove all HTML
Encode output where necessary
Choose the correct encoding depending on the context
Donʼt assume frameworks and libraries use secure defaults.
On Alexaʼs Top 100,000 websites,
75% use a jQuery version older than 2½ years.
On 35% itʼs even older than 5 years.
Node Security Project
Make security part of your build process
- Check for outdated/vulnerable dependencies
- Lint your code, aim for high code coverage in your unit tests
- Check inputs (forms, APIs, etc.) during integration tests:
Invalid input, null bytes, Unicode characters, HTML snippets, XSS vectors, etc.
Use HTTPS with Transport Layer Security (TLS)
The succeeding protocol to SSL
- … for site storing user data
- … for downloads/software updates
- … for the Internet of Things
All your siteʼs content must be served via HTTPS.
Make it stick using the HTTP Strict Transport Security header.
Be aware of possible side channels.
And seal them using Content Security Policy.
Use centralized logging to detect unusual behavior patterns.
Set up automated notifications and alerts.
Security is always an ongoing effort.
Revise your tools and processes when necessary.