4 ms·

I will never src a script to a third party server. Same with fonts. I think it's ironic that we thrash chipmakers for side channel attacks that realistically c

I will never src a script to a third party server. Same with fonts. I think it's ironic that we thrash chipmakers for side channel attacks that realistically couldn't ever be exploited but the same people turn around and call 14 different scripts from 14 different domains to display a 900kb web page. Who really knows who has access to or is tracking access to that code? And what happens when one of them goes down? "The CDN is WAY more reliable than my server." But your server is the least common denominator. Who cares if your scripts load if your server doesn't? For low volume, unless you have redundancy at every level of the stack; you can't get more reliable than one box.

IgorPartola 5y ago
How do you handle things like taking payments?
- zelon88 5y ago
  I haven't had to do that in a while but in the past I would just create external links to the payment processor who then links back when the payment is approved/declined. Obviously you can't reasonably "roll your own" payment provider, but that doesn't mean I need to run their code with my name at the top of the page.
  - toast0 5y ago
    It used to be pretty common to self-host a checkout page, and the server contacts the payment processor. That comes with a security checklist compliance burden these days though. Probably better to send the browser to the processor and wait for them to come back, as you said.
- Nextgrid 5y ago
  You can make an exception for payments (where you rely on the payment processor anyway, so the reliability argument goes away - if the processor is down, the payment will fail even if you self-host the payment script). Of course, embed the payment script only on the actual payment page, even if your processor tells you otherwise and quotes some fraud-related bullshit.
  - samwillis 5y ago
    > even if your processor tells you otherwise and quotes some fraud-related bullshit. You may be right 99.9% of the time. But if your site starts being used by someone automatically testing stolen credit card to see if they work you will be thankful for the automated script detection this gives. Every chargeback cost the vendor $20, now imagine 1k of those in a sort period of time, not pretty. So far I have fortunately not been a victim of this but have read about people who have and it gives me enough fear to stick that script on all pages.
    - Nextgrid 5y ago
      Can't you just enforce 3D-Secure and be done with it?
      - samwillis 5y ago
        I may well be out of date (last looked at it about 18 months ago) but I don’t think all card issuers have implemented 3D secure yet. Although I think there may have been a deadline for them to. Also friction in the checkout process is bad and can contribute to dropouts. You can decide to always enforce 3d secure or to have it only run when banks require/suggest it. Personally I set a cart total threshold above which it’s required and set it only to be applied when banks require it for lower value orders.
- samwillis 5y ago
  Slight aside, most payment services with a Stipe like js self hosted checkout now suggest you include their JavaScript on all pages off your site, not just the checkout. This is so that they can begin to build a profile of how the user/browser moves around the site in order to use ML to prevent fraud. They also require that you dont self host the js. The main use of this is to detect automated scripts running cards on your site to test if they work. Obviously it’s an endless battle as the fraudsters move to using tools such as puppeteer/playwright to simulate a human using a browser.

IgorPartola 5y ago

How do you handle things like taking payments?

zelon88 5y ago
I haven't had to do that in a while but in the past I would just create external links to the payment processor who then links back when the payment is approved/declined. Obviously you can't reasonably "roll your own" payment provider, but that doesn't mean I need to run their code with my name at the top of the page.
- toast0 5y ago
  It used to be pretty common to self-host a checkout page, and the server contacts the payment processor. That comes with a security checklist compliance burden these days though. Probably better to send the browser to the processor and wait for them to come back, as you said.
Nextgrid 5y ago
You can make an exception for payments (where you rely on the payment processor anyway, so the reliability argument goes away - if the processor is down, the payment will fail even if you self-host the payment script). Of course, embed the payment script only on the actual payment page, even if your processor tells you otherwise and quotes some fraud-related bullshit.
- samwillis 5y ago
  > even if your processor tells you otherwise and quotes some fraud-related bullshit. You may be right 99.9% of the time. But if your site starts being used by someone automatically testing stolen credit card to see if they work you will be thankful for the automated script detection this gives. Every chargeback cost the vendor $20, now imagine 1k of those in a sort period of time, not pretty. So far I have fortunately not been a victim of this but have read about people who have and it gives me enough fear to stick that script on all pages.
  - Nextgrid 5y ago
    Can't you just enforce 3D-Secure and be done with it?
    - samwillis 5y ago
      I may well be out of date (last looked at it about 18 months ago) but I don’t think all card issuers have implemented 3D secure yet. Although I think there may have been a deadline for them to. Also friction in the checkout process is bad and can contribute to dropouts. You can decide to always enforce 3d secure or to have it only run when banks require/suggest it. Personally I set a cart total threshold above which it’s required and set it only to be applied when banks require it for lower value orders.
samwillis 5y ago
Slight aside, most payment services with a Stipe like js self hosted checkout now suggest you include their JavaScript on all pages off your site, not just the checkout. This is so that they can begin to build a profile of how the user/browser moves around the site in order to use ML to prevent fraud. They also require that you dont self host the js. The main use of this is to detect automated scripts running cards on your site to test if they work. Obviously it’s an endless battle as the fraudsters move to using tools such as puppeteer/playwright to simulate a human using a browser.