[PM-25012] Add data field to Cipher type, and add functions for client-side parsing of the field.

[nikwithak]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-25012

📔 Objective

This PR adds the data field to the Cipher struct, and adds a function for parsing that field into the appropriate CipherType (Identity, SshKey, Login, SecureNote, Card) on the client-side, rather than consuming the server-provided values.

The function sits unused - after #455 is merged, we should consider adding this to the CiphersClient::get and CipherClient::list functions behind a new feature flag.

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
  team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed
  issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[claude]

Claude finished @nikwithak's task —— View job

---

Code Review Complete

Summary of Changes

This PR adds a data field to the Cipher struct and implements populate_cipher_types() to parse this field client-side into the appropriate CipherType variants (Login, Card, Identity, SecureNote, SshKey). The function is currently unused but intended for future use behind a feature flag after #455 merges.

Key Changes:

• Added data: Option<String> field to Cipher struct (cipher.rs:147)
• Implemented populate_cipher_types() method (cipher.rs:461-475)
• Added VaultParseError error type with SerdeJson variant (error.rs:28-48)
• Updated From<CipherDetailsResponseModel> to include data field (cipher.rs:798)
• Minor visibility changes to support error conversions
• Comprehensive test coverage for all cipher types

---

Critical Issues

⚠️ Backward Compatibility & Data Field Handling

cipher.rs:348 - Missing data field population during encryption

data: None, // TODO: Do we need to repopulate this on this on the cipher?

Issue: When encrypting a CipherView back to Cipher, the data field is always set to None. If the server relies on this field or if it's needed for round-trip operations, this could cause data loss.

Recommendation: Either:

1. Document why data doesn't need repopulation (if server regenerates it)
2. Implement proper repopulation logic
3. Add a test verifying round-trip behavior with data field

---

⚠️ Security - Encrypted Data in String Field

cipher.rs:147 - Untyped encrypted data storage

pub data: Option<String>,

Concern: The data field contains encrypted cipher data as an opaque JSON string. While not a vulnerability per se, this design:

• Makes it unclear whether the data is encrypted
• Could lead to accidental logging/exposure
• Bypasses type-safe encryption patterns used elsewhere

The CLAUDE.md guidelines specifically warn: "Do not log keys, passwords, or vault data in logs or error paths."

Recommendation: Consider:

1. Add documentation clarifying this field contains encrypted data
2. Ensure the field is never logged in error paths
3. Consider a newtype wrapper like EncryptedData(String) to make the encryption status explicit

---

⚠️ Error Handling - Information Disclosure

cipher.rs:461-475 - Detailed error messages

pub(crate) fn populate_cipher_types(&mut self) -> Result<(), VaultParseError> {
    let data = self
        .data
        .as_ref()
        .ok_or(VaultParseError::MissingField(MissingFieldError("data")))?;

    match &self.r#type {
        crate::CipherType::Login => self.login = serde_json::from_str(data)?,
        // ...
    }
}

Issue: serde_json::Error can include portions of the failed data in error messages. Since data contains encrypted vault data, errors could leak encrypted content into logs.

Recommendation:

1. Wrap serde errors to redact sensitive details
2. Or ensure these errors never reach user-visible logs
3. Add tests to verify error messages don't contain sensitive data

---

Suggested Improvements

🎨 Architecture - Consider Server-Side Parsing Flag

cipher.rs:461 - Client-side parsing implications

The PR description mentions this will be used "behind a new feature flag" for client-side parsing instead of server-provided values. However:

Concerns:

1. No feature flag is currently implemented
2. The method is marked #[allow(unused)] which hides the fact it's not integrated
3. The relationship between data field and the type-specific fields (login, card, etc.) is unclear - should both exist simultaneously?

Recommendation:

1. Add the feature flag now (even if disabled by default)
2. Document the migration path: when is data present vs. type-specific fields?
3. Consider adding a helper method like fn should_use_data_field(&self) -> bool to encapsulate the logic
4. Add integration tests showing how this will work with CiphersClient::get and ::list

Example Implementation

impl Cipher {
    #[cfg(feature = "client_side_cipher_parsing")]
    pub(crate) fn ensure_cipher_types_populated(&mut self) -> Result<(), VaultParseError> {
        // Only populate if data exists and type-specific fields don't
        if self.data.is_some() && self.get_type_field().is_none() {
            self.populate_cipher_types()?;
        }
        Ok(())
    }

    fn get_type_field(&self) -> Option<()> {
        match self.r#type {
            CipherType::Login => self.login.as_ref().map(|_| ()),
            // ... other types
        }
    }
}

---

🎨 Code Quality - Missing deny_unknown_fields on Encrypted Structs

card.rs:18, identity.rs:15, login.rs:283, ssh_key.rs:18

The encrypted structs (Card, Identity, Login, SshKey) don't have #[serde(deny_unknown_fields)], while their View counterparts do.

Issue: If the data field JSON contains extra/malicious fields, they'll be silently ignored, which could hide:

• Version mismatches
• Malformed data from attacks
• Bugs in the server

Recommendation: Add deny_unknown_fields to encrypted types for consistency and safety:

#[derive(Serialize, Deserialize, Debug, Clone)]
#[serde(rename_all = "camelCase", deny_unknown_fields)]  // Add this
pub struct Login {
    // ...
}

---

🎨 Test Coverage - Missing Integration Tests

cipher.rs:1378-1744 - Only unit tests present

The tests thoroughly cover parsing individual cipher types, but don't test:

1. Integration with CiphersClient::decrypt after calling populate_cipher_types
2. Behavior when both data and type-specific fields are present
3. Error handling when data format changes between versions
4. Performance with large data fields

Recommendation:

1. Add integration tests in cipher_client.rs showing the intended usage pattern
2. Test the priority: does data override type-specific fields or vice versa?
3. Add a test for backwards compatibility when data is None

---

🎨 Performance - Repeated JSON Parsing

cipher.rs:468-473 - serde_json::from_str called on every access

Currently, populate_cipher_types() must be called manually to parse JSON. If called multiple times (e.g., in different code paths), it re-parses the JSON.

Recommendation:

1. Consider caching the parse result
2. Or ensure the method can only be called once (make it &mut self and clear data after parsing)
3. Document that this is a one-time initialization method

---

🎨 API Design - Public Exposure of Internal Implementation

cipher.rs:461 - pub(crate) visibility

pub(crate) fn populate_cipher_types(&mut self) -> Result<(), VaultParseError>

This method is pub(crate), making it callable throughout the vault crate but:

1. It's not clear when/where it should be called
2. Multiple calls could cause confusion
3. The state transition (unpopulated → populated) is implicit

Recommendation:

1. Keep it private and expose through a better API
2. Or add documentation explaining the state machine
3. Consider a builder pattern or typed state to enforce correct usage

---

Good Practices Observed

✅ Comprehensive test coverage - All cipher types tested with valid/invalid data (tests at cipher.rs:1378-1744)
✅ Proper error propagation - Uses ? operator and custom error types
✅ Consistent serialization - Uses camelCase consistently with existing code
✅ Non-breaking change - data field is Option<String>, maintaining backward compatibility

---

Action Items for Author

Must Address (Blocking Issues)

1. Resolve the data: None TODO (cipher.rs:348) - Either implement or document why it's safe
2. Ensure encrypted data never appears in error messages - Audit error paths
3. Document security properties of the data field

Should Address (Important Improvements)

4. Add deny_unknown_fields to encrypted cipher types for consistency
5. Implement or remove the feature flag reference from PR description
6. Add integration tests showing intended usage with CiphersClient

Nice to Have (Enhancements)

7. Consider state machine for cipher type population
8. Add performance tests for JSON parsing overhead
9. Document the migration strategy from server-side to client-side parsing

---

Notes

• Serialization Compatibility: ✅ The Option<String> type maintains backward compatibility as per CLAUDE.md requirements
• Security Review: ⚠️ Needs attention to ensure encrypted data doesn't leak through error messages
• Test Quality: ✅ Excellent unit test coverage, but integration tests needed

---

[github-actions]

Checkmarx One – Scan Summary & Details – 0294202e-215e-45ac-be50-cc5315c935e2

New Issues (2)

Checkmarx found the following issues in this Pull Request

Severity	Issue	Source File / Package	Checkmarx Insight
	CVE-2025-58754	Npm-axios-1.11.0	details Recommended version: 1.12.0 Description: Axios is a promise based HTTP client for the browser and Node.js. When Axios prior to version 1.12.0 runs on Node.js and is given a URL with the "d... Attack Vector: NETWORK Attack Complexity: LOW ID: GXwA2qzRmyghrx1FwF4GqdP3WtA5UFLQDN5UMkJ21PM%3D Vulnerable Package
	Parameter_Tampering	/crates/bitwarden-uniffi/kotlin/app/src/main/java/com/bitwarden/myapplication/MainActivity.kt: 405	details Method decryptVault at line 405 of /crates/bitwarden-uniffi/kotlin/app/src/main/java/com/bitwarden/myapplication/MainActivity.kt gets user input ... ID: 98tiJODJH7r7i9Q%2F1ziDNx9Qv44%3D Attack Vector

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.7% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

❌ Patch coverage is 97.91123% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 78.60%. Comparing base (2a00b72) to head (15558fb).

Files with missing lines	Patch %	Lines
crates/bitwarden-vault/src/error.rs	0.00%	7 Missing ⚠️
crates/bitwarden-vault/src/cipher/cipher.rs	99.72%	1 Missing ⚠️

Additional details and impacted files

@@                         Coverage Diff                         @@
##           vault/feature/cipher-versioning     #517      +/-   ##
===================================================================
+ Coverage                            78.34%   78.60%   +0.26%     
===================================================================
  Files                                  287      287              
  Lines                                28095    28477     +382     
===================================================================
+ Hits                                 22010    22384     +374     
- Misses                                6085     6093       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.