One often hears that companies care about security, or have it baked into their design. In reality, the actual tasks companies undertake to protect people’s security are limited to what modern website architecture provides naturally. We recognize how important security is for your business. Our security is your security, and we know that failure simply isn’t an option. So we’ve gone far above and beyond. Here is just a sampling of what we do to protect you. If you have any additional questions about how we handle security, please contact us.
XSS Protection
– Default React libraries neuter dangerous information before it is stored in the database.
– The optional Content Security Policy headers are set to allow only our vendors and ourselves to be included on the page. The only caveat being use of appcodes, which are managed. It also neuters inline JavaScript to limit injected JavaScript on all authenticated pages.
– The optional X-Content-Type-Options header is set to “nosniff” which means the browser will not guess what kind of data is being returned. This enforces that each of the pages are properly rendered only when the correct header is present on all authenticated pages.
CSRF Protection
– All of our user-facing routes use React, data is fetched from the API asynchronously, authenticated by a JWT access token.
Clickjacking Protection
– The site utilizes the optional X-Frame-Options header which prevents the site from being framed by an adversarial domain.
Command Injection
– We do not ever pass user based content to system shell commands. All of our web-facing server-side code is written in native Node J.
SQL Injection
– All user input is sanitized prior to entering it into the database. Our ORM automatically handles this issue.
– All database entry points are parameterized to prevent malicious code from breaking out of SQL commands.
Cookies
– Cookies are set per user and last up to 31 daysand are disabled by both server and browser logic upon expiration.
– Session data is not saved in the cookie itself, just the session ID. Session data is stored server-side.
– We set the HTTPOnly flag on all cookies to prevent them from being read by malicious JavaScript.
– We don’t allow authentication cookies to be read by any pages outside of the application.
Use of 2nd Factor Authentication
– We require use of 2nd Factor Authentication on our CDN provider.
– We require use of 2nd Factor Authentication on our DNS/Domain provider.
– We require use of 2nd Factor Authentication on our trouble ticketing system.
– Second Factor Authentication can optionally be enabled on a per-account basis – we do recommend this to prevent brute force attacks and password re-use attacks.
PII
– We do not use credit cards.
– We do not require our users do not upload addresses, phone numbers, social security numbers all which might give away personal information.
Software Updates
– The primary and test systems are updated and patched for security vulnerabilities on at least a weekly basis.
