What Are Your Security Standards?
Security Information
Inside DepositFix, we keep data about contacts (name, email, contact id from Stripe) and transactions (date, amount, product name, transaction id from Stripe). This information is kept to help you segment the purchases. Credit card information (number, CVC, exp date) is never sent to our servers, we use stripe tokens to charge the cards, which are not stored in our database.
Since we don’t send or store information about the credit cards on our servers, DepositFix doesn’t have to comply with the full PCI spec. However, the process is PCI compliant because Stripe or PayPal covers most requirements. On our side, we use SSL encryption everywhere (Browser -> Stripe -> DepositFix -> HubSpot). The database only allows connections from the application itself and blocks everything else.
DepositFix is backed by Amazon AWS, which is a proven and secure infrastructure provider:- Amazon RDS (Postgres) as storage- Amazon S3 as CDN for CSS and JS files- Cloudflare as DNS provider- The application is deployed as docker containers with auto-recovery mode.
If HubSpot operates with 2 (or more) availability zones, what about DepositFix?
DepositFix is available in 2 availability zones; if one of Amazon’s data centres goes down, then we can still accept payments from your clients.
How are data backups managed?
Database backups are automatically created every day and kept for seven days.
What framework/language is used to implement DepositFix?
Backend: Java + SpringBoot + PostgreSQL. Frontend: AngularJs
What access controls are there around the contact & transaction data does DepositFix store and is the live environment distinct from the dev/staging environment?
Production and test environments are separated and run in different virtual networks.
What structures are in place to prevent ‘leakage’/‘cross-talk’ between their client's data sets? (e.g. altering parameters or injecting something that makes me ‘jump’ into another client data set or any compromised by cookie tweaking)?
We use SpringSecurity, which provides protection against attacks like session fixation, clickjacking, and cross-site request forgery.
All private APIs (used from inside the application) are blocked for cross-domain requests. Also, there are filters checking for access rights for specific objects.
There is a number of public APIs that allow outside access (actual payment from HubSpot form). The only ID exposed publicly is the User ID, but it’s a 32-char random String UUID which is hard to brute force. Even if you know the other customer ID, all you can do is to submit payment to their account.
Is There Monitoring?
We monitor Stripe and HubSpot APIs on the backend; if either is down, we show an error message to the user before injecting the form. For monitoring our services, we use UptimeRobot and Sentry.