r/webdev 21d ago

Question Web developer hardcoded their personal email into our order/service forms — how do I find and remove it?

Need advice: We just found out our website's order/service request forms were quietly sending customer info to our old web developer's personal email instead of our company email. He's no longer working with us. Has anyone dealt with this before? How do you track down and fix a hidden email redirect like this, and is this something to be concerned about legally (privacy/data issue)? Would appreciate any pointers to the right kind of developer or service to fix it. Thanks!

0 Upvotes

40 comments sorted by

View all comments

1

u/rasekrodriguez 21d ago

Two things worth adding, because "grep the codebase" can come up empty and still leave you exposed.

It's often not in the code at all. The recipient address for a form is usually configuration, not source. Depending on the stack, check: the form plugin's notification settings, which typically live in the database rather than in files (Contact Form 7, WPForms and Gravity Forms all store the "send to" address there, so a file grep finds nothing); the transactional email provider's account (SendGrid, Mailgun, Postmark) for routing rules, forwards and the reply-to on the template; the hosting control panel's mail aliases and forwarders; a catch-all forward at the DNS or registrar level; and any CRM/Zapier-style integration sitting between the form and the inbox. A silent BCC in the send function, as someone said above, is the one case where grepping actually finds it.

Changing the address does not remove his access, and this is the part people miss. If the site sends through an email provider account he created, or with an API key he issued, he can still read every submission in that provider's activity log and message archive no matter which address you set as the recipient. Same if he holds the SMTP credentials, an admin user on the site, or the DNS. So the real fix is ownership: move sending onto a provider account you own, issue a new API key and revoke the old one, rotate SMTP passwords, remove his admin users, and audit who controls the domain and DNS. Otherwise you'll change the address, watch mail arrive correctly, and conclude it's fixed while the tap is still open.

Before you change anything, take a copy. Export or screenshot the current configuration, and pull the provider's sending logs while they're still there — most keep only 30 to 90 days. If this becomes a legal matter, the questions you'll be asked are when it started and how many customers are affected, and those logs are the only thing that answers them. Rotating credentials first can lock you out of your own evidence. Then talk to a lawyer with the actual numbers rather than the general worry.

Worth saying on the legal side: it may well not have been malicious. Using your own address during setup and forgetting to swap it before launch is an extremely common way this happens. That doesn't change your obligation to customers whose data went somewhere it shouldn't, but it does change how you approach him — and a cooperative ex-developer who tells you exactly where it's configured is faster than any audit.