Security Practices | Efficient Dollar

This page provides a more detailed overview of the security practices used by Efficient Dollar. It is intended for users who want a deeper understanding of how we protect data, including developers, security-conscious individuals, and potential partners.

For a higher-level summary, see our Security page. For information on privacy and financial data, see our Privacy Policy and Data Protection Notice.

1. Architecture Overview

Efficient Dollar is built as a modern web application with the following characteristics:

A web front end served over HTTPS
Server-side logic and APIs running on managed infrastructure
Data stored in managed, cloud-hosted databases
Third-party services for authentication, email, payments, and financial data connectivity

We follow a defense-in-depth approach, layering controls at the network, application, and data levels.

2. Transport Security

All traffic between client devices and Efficient Dollar is encrypted using TLS (HTTPS).

We:

Enforce HTTPS for all primary application endpoints
Use TLS certificates managed by our hosting/CDN providers
Prefer modern cipher suites as provided by our infrastructure

Users should keep their browsers and operating systems updated to benefit from the latest security improvements.

3. Data at Rest

Application data is stored in managed databases and storage services that provide encryption at rest.

Where applicable, we:

Use provider-managed encryption for databases and object storage
Limit storage of sensitive data to what is strictly necessary
Avoid storing highly sensitive secrets such as bank login credentials or full payment card numbers

Financial credential handling is delegated to providers such as Plaid and payment processors (e.g., Stripe for future subscriptions).

4. Application Security

4.1 Authentication and Sessions

Efficient Dollar uses a modern authentication system that supports:

Sign-in with trusted identity providers (e.g., Google)
Secure session management with signed tokens and/or cookies
Session expiration policies to reduce long-lived access

We avoid storing plain-text passwords. When password-based auth is used, passwords are processed using industry-standard hashing algorithms.

4.2 Authorization and Access Control

We implement server-side checks to ensure that users can only access:

Their own data
Resources explicitly associated with their account

We design APIs and database queries to enforce authorization decisions on the server, rather than relying solely on client logic.

4.3 Input Validation and Output Encoding

We use a combination of:

Input validation on server endpoints
Parameterized database queries or ORM features
Proper output encoding in templates

These measures help protect against common vulnerabilities such as injection attacks and cross-site scripting (XSS).

5. Infrastructure and Deployment

Efficient Dollar runs on reputable cloud and hosting providers that implement strong physical and network security controls.

Our practices include:

Using managed databases and managed runtime environments where possible
Restricting direct access to production infrastructure
Separating development and production environments
Deploying changes through controlled build and deployment pipelines

We avoid ad-hoc changes on production systems and prefer configuration-as-code where practical.

6. Secrets and Configuration Management

We treat secrets such as API keys, database credentials, and signing keys with care.

Our approach includes:

Storing secrets in environment variables or dedicated secret-management mechanisms
Avoiding hard-coded secrets in source code or client-side bundles
Rotating sensitive keys if compromise is suspected or when required

We also aim to minimize the number of services and components that have access to each secret.

7. Financial Data and Plaid Integration (Future)

When bank connectivity via Plaid is enabled, our security posture will include:

Delegating bank authentication to Plaid and financial institutions
Never storing or logging bank login credentials
Receiving only the financial data necessary for budgeting and analytics (e.g., balances, transactions, account identifiers)
Storing financial data in encrypted databases
Providing users with controls to disconnect accounts and request deletion of stored financial data

For more details on data flows and legal bases, see the Data Protection Notice.

8. Payments and Subscriptions (Future)

When paid plans are available, we plan to:

Use a PCI-compliant payment processor (such as Stripe) to handle payment details
Avoid storing full payment card numbers on our servers
Keep billing-related data (such as subscription status and last 4 digits of cards) separate from application logic where appropriate

This separation reduces the scope of systems that handle payment-related data.

9. Logging and Monitoring

We maintain logs to help:

Diagnose issues and performance problems
Monitor for unusual or suspicious activity
Support security investigations when necessary

Where possible, logs avoid storing sensitive personal or financial data. Access to logs is restricted to authorized personnel.

10. Access Control and Least Privilege

We apply the principle of least privilege across systems and roles. This means:

Limiting access to production data to a small set of authorized individuals
Granting access only to the extent needed to perform specific duties
Reviewing and adjusting access when roles change

11. Backups and Resilience

We rely on provider-level or managed backup mechanisms for critical data. Our goal is to:

Ensure that data can be restored in the event of major failures
Reduce the risk of data loss due to hardware or infrastructure issues

Backups are subject to the same security controls (such as encryption) as primary storage.

12. Vulnerability Management

We aim to keep dependencies and platform components reasonably up to date.

Our practices include:

Applying security updates as they become available and practical
Monitoring for advisories affecting key dependencies
Refactoring or replacing components when they present ongoing security risk

We encourage responsible disclosure from external researchers and users who find potential issues (see the Security page for contact details).

13. Your Responsibilities

While we take security seriously, users also play an important role in protecting their accounts. We encourage you to:

Use strong, unique passwords for email and identity provider accounts
Enable multi-factor authentication (MFA) where available
Keep browsers and devices up to date
Use trusted networks when accessing sensitive information

If you suspect unauthorized access to your account or data, contact us immediately at support@efficientdollar.com.

14. Changes to These Security Practices

As Efficient Dollar grows and introduces new features (such as Plaid integrations and subscription plans), we may update these Security Practices.

We will revise the “Last updated” date at the top of this page, and in some cases may provide additional notice through the application or via email.

If you have any questions about these practices, please contact us at support@efficientdollar.com.