This post originally started out as a list of tips on how to break web applications but quickly morphed into a pre-release checklist.
So here are a couple of things to validate before you press the ‘go-live’ button on that wonderful web application of yours.
- Does the application handle extremely large input? Try copying a Wikipedia page into an input field. Strings can be too long and overflow database models.
- Does it handle boundary values properly? Try extremely large or small values; Infinity is a good one.
- Do you have validation? Try submitting forms with no entry.
- Do you validate mismatched value types? Try submitting strings where numbers are expected.
- Has all web copy been proofread and spell-checked? Typos are bad for reputation.
Localization (L10n) and Internationalization (I18n)
- Do you support Unicode? The Turkish i and German ß are two quick tests.
- Do you support right-to-left languages? CssJanus is a great tool for flipping pages.
- Time zones and daylight saving time changes.
- Time formats: 12 and 24 hour clocks
- Date formats: mm/dd/yyy vs dd/mm/yyyy
- Currencies in different locales.
- Does your web app work well on slow connections? You can use Chrome or Fiddler to simulate this.
- What happens when abrupt network disconnections occur while using your web application?
- Do you cut off expensive operations when the user navigates away or page is idle?
Usability + UX
- Does the application work well across the major browsers you support (including mobile)?
- Does the application look good at various resolution levels? Try resizing the window and see what happens.
- Is your application learnable? Are actions and flows consistent through the application? For example, modal dialogs should have the same layout regardless of the action triggering them.
- Do you have your own custom 404 page?
- Do you support print?
- Do error messages provide enough guidance to users?
- Are all links valid?
- Do you validate all input?
- Are all assets secured and locked down?
- Do you grant least permissions for actions?
- Ensure error messages do not reveal sensitive server information.
- Have you stripped response headers of infrastructure-revealing information? E.g. server type, version etc.
- Do you have the latest patches installed on your servers and have a plan for regular updates?
- Do you have a Business Continuity / Disaster Response (BCDR) plan in place?
- Are you protected against the Owasp Top Ten?
- Do you have throttling and rate limiting mechanisms?
- Do you have a way to quickly rotate secrets?
- Have you scanned your code to ensure no valuable information is being released?
- Did you lint your CSS and JS (see JSLint, JSHint, TSLint)?
- Do you have unit, integration and functional tests?
- Have you run Google’s Page Speed and Yahoo’s YSlow to identify issues?
- Are images optimized? Are you using sprites?
- Do you use a CDN for your static assets?
- Do you have a favicon? Helps to prevent unwanted 404s since browsers auto-request for them.
- Are you gzipping content?
- Have you considered moving to HTTP2?
- Do you have test and staging environments?
- Do you have automated release pipelines?
- Can you roll back changes?
- Do you have a way to track errors and monitor this with logging?
- Do you have a plan to handle customer reported issues?
- Have you met all legal and compliance requirements for your domain?
- Have you handled SEO requirements?
These are just a few off of my head – feel free to suggest things I missed out. I should probably consider transferring these to a Github repo or something for easier usage.