Bank account and credit card information
LegFi does not store any bank account or credit card data in our platform or on our servers. When you input bank account or credit card data, you are actually providing it directly to our payment processor, Stripe. Here is a link about Stripe and their security: https://stripe.com/docs/security/stripe -- they are a multibillion dollar company and are level 1 PCI compliant. LegFi uses a process called tokenization which allows us to use a token to process payments via Stripe on LegFi, however, this token has zero value outside of LegFi if someone were to access it. This means that if someone were to hack into your LegFi account (which is very unlikely), they wouldn't be able to access any of your bank account or credit card data because it is not anywhere in our site or on our servers.
In addition to not storing any sensitive payment data, we scan our servers each quarter for PCI compliance. All servers have received an "A" security rating on the most recent scan.
Access to LegFi
Our front-facing application authenticates requests with our API via a JWT token. This also verifies origin of requests and denies all tokens from an invalid domain. To add an extra layer of security, we went against the common practice of signing all JWT tokens with the same secret. Instead, each individual user account has its own secret that is used to sign the JWT
When an email statement is sent to primary and auxiliary email addresses, it creates a temporary JWT that allows access to the account from that email link. However, the JWT expires after a set period of time and each JWT is unique to each email sent. This temporary JWT provides you access to LegFi without sharing a username and password with the primary user. This has become common practice in invoicing systems like Freshbooks and PaySimple.
General security
For our application layer itself, we are using best practices in both the frontend application and our core API products. We have full input validation and sanitization occurring within both pieces of the application. This is somewhat redundant; however, it allows us to feel very secure about the input we receive from end users and protect against XSS and CSRF attacks. Our API layer is very strict about the data that we can import. It also fully utilizes the ORM we are using to help limit any exposure to SQLi attacks. The API layer also validates all requests made using standard protocols such as CORS to manage that a client has the proper authority to make requests.