Suppress credit card false positives on serialised decimal numbers

[seancraven]

Hi,

I hope your well, we've been using your pii tool at work! We have some false positives on some serialised floats, this solves it from my testing locally.

As an aside. We also have some issues with phone numbers and zip codes, triggering on serialised data, that is benign. This is a bit less straightforward because there aren't any simple rules like the one implemented here.

https://en.wikipedia.org/wiki/Payment_card_number#Issuer_identification_number_(IIN)

Objective

Stop CREDIT_CARD false positives on serialised floating point numbers. The credit card detector only rejected a candidate when the preceding byte was alphanumeric, so the fractional part of a decimal such as 3.4111111111111111 or 3,4111111111111111 (13–19 digits, supported prefix, Luhn-valid) was reported as a card.

Changes

• Add follows_decimal_separator in crates/core/src/lib.rs and suppress only contiguous digit candidates preceded by a digit and . or ,.
• Inspect the complete candidate before applying the decimal check, preserving normal card validation for candidates containing spaces or hyphens.
• Positive tests cover cards after punctuation without a leading digit and formatted cards after 3. / 3,, including exact finding offsets.
• Negative tests cover decimal fractions containing 13, 16, 19, and 20 digits.
• Document the plain-text comma ambiguity in the README and documentation overview.

Known ambiguity

3,4111111111111111 can represent a comma-decimal number or two CSV fields containing 3 and a card number. Plain-text scanning cannot distinguish those interpretations, so the contiguous card candidate is suppressed. Applications scanning CSV should parse it and scan each field separately. Formatted candidates such as 3.4111-1111-1111-1111 still undergo normal card checks.

Verification

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo test --workspace --all-features
• New or changed detection behavior includes positive and negative tests
• I reviewed the diff for unrelated refactoring or duplicated binding logic

Python, Node, and WASM package tests were not run locally; the bindings call the same core detector.

[sidmohan0]

Thanks for contributing this, and glad you’re using this at work! The decimal fix makes sense. I did spot an edge case: the new check can also suppress a formatted card like 3.4111-1111-1111-1111, which could appear in a numbered list (not an issue if there was a space after the period) . I’ll verify that with a regression test and add a small refinement on top of your change so we preserve the decimal fix while still detecting formatted cards.

[sidmohan0]

Thanks again, Sean! I added a small refinement and regression test so formatted cards still get detected while preserving your decimal fix. The checks passed, and I’ve documented the remaining comma ambiguity: plain text can’t distinguish a comma-decimal number from two CSV fields, so CSV should be parsed and scanned field by field. Target release v0.4.4.