I recently reviewed several backend systems written in typescript using the expressjs framework.
They each had something like
everything_about_bob : PERSON =
retrieve_everything_about_a_person_from_the_database_about(id_for_bob)
what_we_can_say_about_bob : PERSON_OMITTING_SECRETS =
without_secrets(everything_about_bob)
display(what_we_can_say_about_bob)
which properly worked, but
- The database would be better at enforcing this; the sensitive information should never have been retrieved from the database.
- Security testing of what_we_can_say_about_bob was insufficient or entirely absent.
- It would have been nice to have had a verify_there_are_no_secrets before the display.
- The type-checking wasn’t helping us as much as it could have. Omittining meant “no longer required” rather than “prohibited.” Every teaching example that I looked at and every LLM that I chattedwith failed on this point.
Typescript was designed to make sure that things weren’t missing rather than to make sure that extra stuff wasn’t there. While it is possible to use typescript to help enforce prohibitions, it isn’t natural or common.
So, it is a powerful extra line of defense that isn’t used. It should be.
Any or all of these four factors could help ensure that programming errors that compromise privacy aren’t silently making their way into production in the future.
When you write or audit code privacy-sensitive code, which, if any, of these four are you utilizing?
What else are you doing?
Let me know in the comments, and, as always, I will add to my collection.
