6 ms·
This is why, when I recently built a credit card form, we didn't include any trackers or third-party code (beyond our vendor's). No dependencies at all—our ven
by saryant 9y ago
This is why, when I recently built a credit card form, we didn't include any trackers or third-party code (beyond our vendor's). No dependencies at all—our vendor also has no dependencies in the JS we use to implement the CC form.
That did mean no jQuery, no Google Analytics, no NPM modules and we had to build it as a standalone page outside our React setup, but it's worth it to be able to definitively inspect every line of code and provide a CSP that locks that page down tight to just our subdomain and our vendor's.
- monokrome 9y agoHere's hoping you do the same for your login form! :D
- awq123 9y agoIncredible
- aristeol2000 9y agovery interesting!
- asd1 9y agof
- SherPahlavan 9y agoGhbdtn rfr ltkf
- deleted 9y ago[deleted]
- cesarb 9y agoThat's the same as protecting just the login page with https. What prevents code outside the form page from replacing the link which goes to the form page?
- martin-adams 9y agoExactly my thought. I guess that would mean it would need some intimate knowledge of the target site this reducing the scalability of the attack. But then again, thee are some clever people out there who could automate it.
- bsilvereagle 9y agoWhy not host a validated version of jQuery on your server instead of relying on a CDN?
- bubble_boi 9y agoThanks for this. I've added a note to the post. "...consider having dedicated, lightweight pages for login and credit card collection that don’t ship any third party code (npm packages, advertising, analytics, GTM, etc.)"