Depoflow SecurityBiztonsági Architektúra

Depoflow is designed so that full payment-card numbers and CVV security codes are not stored in the Depoflow application database. Payment-card processing is handled by the applicable payment provider according to its own systems and security requirements.

The exact payment-data boundary depends on the production integration and should be verified against the deployed payment flow.

Depoflow uses Clerk for authentication and identity management where configured. Application authorization should rely on the authenticated identity and server-side authorization context rather than trusting identifiers supplied directly by the client.

Depoflow is designed as a multi-tenant application in which business data is associated with an appropriate business account and authorization context. Requests should be evaluated against that context before customer, appointment, payment-related, or evidence data is returned or modified.

Where Row-Level Security is enabled in the production database, database policies can provide an additional authorization boundary between business accounts. RLS should complement, rather than replace, application-level authorization and server-side access controls.

Webhook requests from external providers should be treated as untrusted until their authenticity has been verified using the provider's documented signature or verification mechanism.

The production implementation should also validate relevant event identifiers, timestamps, object state, and idempotency where applicable.

Payment events such as authorization results, captures, refunds, and disputes should only affect application state after successful verification through the applicable payment provider's trusted event mechanism.

Google Calendar connections use OAuth rather than requiring Customers to provide their Google account passwords to Depoflow. Access should be limited to the scopes required by the enabled calendar functionality.

OAuth credentials and tokens must be protected according to the actual production storage and secret-management architecture.

Depoflow is designed to process and retain information relevant to its intended booking, payment-workflow, synchronization, security, and evidence functions. Customers should avoid entering unnecessary sensitive information, payment credentials, or authentication secrets into the Platform.

Data transmitted between users, Depoflow infrastructure, and supported third-party services should be protected using encrypted transport mechanisms appropriate to the service. The exact encryption controls should be documented against the production infrastructure.

Access to production systems and sensitive operational data should be restricted according to role, business need, and the principle of least privilege. Administrative access should be authenticated and auditable where technically supported.

Application secrets, API credentials, signing keys, OAuth credentials, and other sensitive configuration values should be stored server-side using appropriate secret-management mechanisms and must not be embedded in client-side bundles or committed to public repositories.

Technical logging may be used to support authentication, troubleshooting, security monitoring, webhook processing, application integrity, and auditability. Logs should avoid unnecessary sensitive information and be retained according to the applicable operational and legal requirements.

Depoflow is intended to maintain procedures appropriate for identifying, containing, investigating, and remediating security incidents. Depending on the nature of an incident, response activities may include access restriction, credential rotation, investigation of affected systems, and applicable customer or regulatory notifications.

Depoflow relies on third-party infrastructure and services for functionality such as authentication, payments, calendar integration, hosting, communications, or monitoring. Each provider operates under its own security practices and contractual terms.

Depoflow does not treat third-party security as a substitute for its own application-level authorization and operational controls.

Security should be considered throughout development through practices such as dependency management, code review, authorization testing, input validation, webhook verification, and review of security-sensitive changes.

Any statement regarding formal penetration testing, independent audits, certifications, or recurring security assessments should only be published once the relevant activity has actually been completed.

Security researchers who identify a potential vulnerability should report it privately and provide enough information to reproduce and investigate the issue.

No internet-connected system can be guaranteed to be completely secure. Security controls reduce risk but cannot eliminate every possible vulnerability, outage, credential compromise, third-party failure, or other security event.

Customers also play an important role in protecting their data. This includes securing account credentials, limiting internal access, protecting integration credentials, using appropriate authentication practices, and promptly addressing suspected unauthorized access.

Depoflow's security framework is intended to support appropriate technical and organisational measures under Article 32 GDPR, taking into account the risks associated with the relevant processing activities.

The appropriate security measures depend on the actual processing, system architecture, and risk profile. This page is not a certification of GDPR compliance.

Potential security vulnerabilities should be reported privately through the designated security contact: