You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -125,3 +125,15 @@ The `PopBrowserInjector` uses Playwright's `connectOverCDP` for cross-origin ifr
125
125
- A brief note in the PR description confirming you verified the domain is controlled by the payment processor, not a reseller or affiliate
126
126
127
127
If you have an idea for a feature or a bug fix, please open an issue or submit a Pull Request!
128
+
129
+
## Open Discussion: masked_card Encryption
130
+
131
+
Currently, `masked_card` values (e.g., `****-4242`) are encrypted at rest in SQLite using AES-256-GCM. The dashboard API decrypts them before display.
132
+
133
+
We're seeking community input on whether this encryption is necessary:
134
+
-**Current state**: Masked card values like `****-4242` are encrypted in `pop_state.db` and decrypted on read
135
+
-**Argument for keeping**: Defense-in-depth — even masked data gets encryption
136
+
-**Argument for removing**: `****-4242` is not PCI-sensitive data (PCI DSS explicitly allows truncated PAN display). Encryption adds complexity and caused a dashboard display bug where raw ciphertext was shown instead of the masked value
137
+
-**Note**: Full card numbers are never stored in the database — only the masked form
138
+
139
+
If you have opinions on this, please open an issue or discussion.
0 commit comments