# Supplier Credential Security Whitepaper ## 🔐 Executive summary Hotel distribution stitches together customers, suppliers, inventory, pricing, orders, and operational support. Every supplier credential held by TTDbooking is a key into someone else's production system, which is why we classify them as high-sensitivity assets rather than ordinary configuration data. TTDbooking protects those assets with overlapping controls organised around five ideas: grant the narrowest workable privilege, show the secret in as few places as possible, keep full credentials inside the runtime path, make every change traceable, and never let a security control break a live booking flow. This paper sets out the reasoning behind that model and the engineering controls that implement it. It is written for customers, suppliers, partners, and security reviewers who want to understand where credential exposure risk exists in the platform and what we do to shrink it. ## Scope The material below applies to how supplier credentials are managed and consumed inside the TTDbooking platform: - Creating, viewing, updating, and deleting supplier credentials. - How credentials render in management APIs and in the admin interface. - How credentials are consumed on supplier runtime execution paths. - How credentials are handled inside audit records, log queries, session views, and support workflows. - How supplier credential schemas drive sensitive-field identification and display behaviour. This is a technical description of platform behaviour. It is not a contract, a data processing agreement, a service level commitment, or a compliance attestation, and it does not modify any agreement you hold with TTDbooking. ## Security objectives The controls in this document exist to satisfy six objectives: 1. A full credential is read only where a business execution path genuinely needs it. 2. Surfaces outside the runtime path do not render complete secrets by default. 3. Management screens, log queries, audit records, and support tooling operate on masked values or references by default. 4. Every credential-affecting change leaves a trail. 5. Search, pricing, booking, and cancellation keep working with these controls switched on. 6. Onboarding a new supplier ships with its sensitive-field marking, display rules, and regression tests — not as a follow-up. ## Design principles ### Minimal exposure Where a secret is stored matters less than how often it is put on screen. A credential that is safely encrypted but printed into every admin page, support ticket, and exported log is still a credential at risk. TTDbooking therefore trims secret rendering out of admin pages, API responses, audit entries, log queries, and support flows. When something needs to be identified as a specific credential, we lean on business metadata — supplier, account alias, environment, status, credential ID — rather than on the secret itself. ### Least privilege The ability to manage credentials belongs to roles that have an operational reason to hold it. Runtime services read only the credential needed for the supplier call in front of them. Management and support tooling stays on masked or reference data whenever that is enough to do the job, which in practice is nearly always. ### Separation of management plane and runtime plane We treat "displaying a credential" and "using a credential" as two distinct security boundaries. Authenticating against a supplier requires the real value. Rendering a list, resolving an entity configuration, reading a log, or reviewing an audit entry requires nothing more than an identifier or a masked value. Keeping the two planes apart removes exposure without costing availability. ### Traceability Create, update, and delete are the operations that change the security posture of a credential, so each one is recorded. Those records serve governance, incident investigation, and customer support — which is precisely why they must not quietly become a second plaintext copy of every secret on the platform. ### Business continuity Supply-chain execution has to stay stable. Credential controls are built into the core workflows rather than bolted alongside them, so protection and reliable search, pricing, booking, and cancellation are not in tension. ## Layered security architecture ### Layer 1 — Input and schema controls Each supplier's authentication structure is described by a credential schema, and sensitive fields are identified from field semantics. The field names commonly treated as sensitive are: | Sensitive field | | --------------- | | `password` | | `secret` | | `apiKey` | | `token` | | `licenseKey` | | `securityKey` | | `authorization` | Those schemas are what: - Determine the input control type used in the admin UI. - Flag which fields are sensitive. - Drive masked rendering. - Give every newly onboarded supplier the same security baseline from day one. ### Layer 2 — Management surfaces mask by default In the admin interface and in management APIs, supplier credentials come back masked. Sensitive fields are replaced with mask placeholders, so an administrator doing routine work — opening a record, taking a screenshot, forwarding a page, collaborating on a support case — does not have a live secret in front of them. Editing a non-sensitive setting does not force you to re-enter the secret. The platform preserves the stored value, so a masked placeholder never overwrites the real credential. ### Layer 3 — Runtime isolation Supplier calls need real credentials to authenticate, and that is the one place the full value is read. Complete credentials are confined to those supplier execution paths and are not propagated outward into management display, entity configuration, log query, or audit rendering. ### Layer 4 — Audit and observability safety Audit records keep who acted, what was acted on, the action type, when it happened, and the surrounding context. The payloads themselves carry masked copies or safe metadata, so the audit store never turns into another place secrets live in the clear. Log query results, session views, and support investigation output are scrubbed for sensitive values before they are shown, which keeps troubleshooting and cross-team collaboration from becoming an exposure route. ### Layer 5 — Reference-based configuration When a component needs to point at a credential rather than read it, it stores a reference instead of a copy of the credential content. Fewer duplicated secrets means a smaller blast radius and a much clearer picture of who actually owns each credential. ## Credential lifecycle ### Create The submitted fields are validated against the supplier's credential schema. The management response comes back masked, so the act of creating a credential does not immediately echo the secret back over the wire. ### View Sensitive fields are masked. What is surfaced instead is identifying metadata: credential ID, name, supplier, status, environment. ### Update A mask placeholder submitted in an update means _keep the stored secret_. This closes a well-known failure mode in which an administrator edits one unrelated field and unintentionally writes the literal placeholder string back over a working credential. ### Use Full credentials are read only on supplier runtime execution paths, and only where external supplier authentication requires them. ### Delete Deletion is recorded in the audit trail. As everywhere else, the audit record contains no plaintext secret. ## Implemented controls | Control | Customer value | | ------------------------------------------- | ---------------------------------------------------------------------------------------- | | Default masking on management surfaces | Cuts exposure during routine viewing, screenshots, forwarding, and support collaboration | | Safe edit semantics | Stops masked placeholders from overwriting real credentials | | Audit-safe copies | Keeps traceability without copying plaintext secrets into audit records | | Runtime isolation | Confines complete credentials to the supplier execution paths that need them | | Reference-based configuration | Cuts down unnecessary internal copies of secrets | | Log query sanitization | Cuts exposure during troubleshooting, session review, and export workflows | | Schema-based sensitive field identification | Applies one consistent security baseline to every newly onboarded supplier | | Regression coverage | Keeps masking, safe edit, reference, and log-read sanitization from silently regressing | ## Auditability Security claims are only worth as much as the checks behind them. Each of the following is directly reviewable: - Whether management API responses mask sensitive fields. - Whether update APIs preserve the stored secret when a mask placeholder is submitted. - Whether audit payloads are free of plaintext secrets. - Whether business entity configuration holds credential references rather than copied credential content. - Whether log query, session view, and support export output is sanitized. - Whether newly added supplier schemas mark their sensitive fields. - Whether unit and regression tests cover the key exposure paths. ## Recommendations for customers and suppliers Platform controls work best alongside sound operational habits on your side. We suggest you: - Issue a separate credential per environment. - Issue a separate account per system, supplier, or business purpose. - Review who holds credential-management roles on a regular cadence. - Keep plaintext secrets out of email, chat, screenshots, and documents. - Rotate after staff changes, suspected exposure, a permissions mistake, or a security incident on the supplier side. - Send and update credentials only through the secure channel you have agreed with us. ## Standards this model draws on The design above follows established public guidance. Each source below maps to specific controls in this document. | Source | Cited excerpt | TTDbooking control mapping | | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) | "centralize the storage, provisioning, auditing, rotation and management of secrets" | One credential store, audit records, runtime isolation, and reference-based configuration keep secret copies from scattering. | | [OWASP Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) | "building application logging mechanisms, especially related to security logging" | Log query, session view, and support investigation output is sanitized so display paths do not leak secrets. | | [NIST SP 800-57 Part 1 Rev. 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) | "guidance and best practices for the management of cryptographic keying material" | Credentials are handled as high-sensitivity access material with lifecycle, access-boundary, audit, and minimal-exposure controls. | | [NIST SP 800-52 Rev. 2](https://csrc.nist.gov/pubs/sp/800/52/r2/final) | "Selection, Configuration, and Use of Transport Layer Security" | TLS is the transport-protection baseline for both credential management and business execution traffic. | | [RFC 8446: TLS 1.3](https://www.rfc-editor.org/rfc/rfc8446) | "confidentiality and integrity for the data" | Current TLS semantics back the confidentiality and integrity goals for data in transit. | | [RFC 6750: OAuth 2.0 Bearer Token Usage](https://www.rfc-editor.org/rfc/rfc6750) | "primary security consideration when using bearer tokens" | Tokens and API keys are treated as possession-sensitive material and hidden from non-essential display surfaces by default. | | [MITRE CWE-532](https://cwe.mitre.org/data/definitions/532) | "Insertion of Sensitive Information into Log File" | Log query, session view, and support export output is sanitized to limit sensitive-information exposure through logs. | | [MITRE CWE-798](https://cwe.mitre.org/data/definitions/798.html) | "Use of Hard-coded Credentials" | Credentials do not belong in code, static documents, or uncontrolled configuration; managed credential records back both management and runtime paths. | ## Closing Credential security is not one feature you can point at — it is a system of controls spanning product design, engineering implementation, and day-to-day operations. Default masking, runtime isolation, audit-safe copies, reference-based configuration, log sanitization, and schema-driven governance each remove a different slice of unnecessary exposure, and together they keep supplier credentials out of the places they have no reason to be. ## Questions or a deeper security review? Write to [integrations@ttdbooking.com](mailto:integrations@ttdbooking.com) and we will route your request to the right team. --- Full API reference: [developer.ttdbooking.com/hotel-api/docs](https://developer.ttdbooking.com/hotel-api/docs)