Hackers monitor indie hackers looking for soft targets

Building a business is difficult. Whilst we may cut corners when bootstrapping be aware that security, especially around payments, is something you need to take seriously.

Hackers are constantly monitoring IndieHackers, ProductHunt, and co searching for unprotected payment endpoints. https://twitter.com/PierreDeWulf/status/1280526239267196931

This can cause major business-crippling problems. Quincy Larson describes how their Stripe endpoint was used to test credit cards - causing an instant $53,000 liability that thankfully he managed to resolve through sheer tenacity.

I quickly scrawled out some numbers on my graphing paper.
$15 times 3,537 transactions is...
My heart started pounding. My mouth went dry.

So be bold, be brave, but also be sure the safe is locked.

  1. 5

    I have recently uploaded a video about
    Django Security Checklist - Prevent your website from getting hacked

    1. 2

      That was helpful! I made some of your suggested changes to my django app

      1. 1

        @jerryalex Glad, you liked it. 😃

    2. 2

      Such a great resource. Would love to connect.

      1. 2

        Thanks for the appreciation.
        You can reach out to me over email [email protected]

  2. 2

    Thank you, much appreciated reminded to take this stuff seriously.

  3. 2

    What are the best practices for preventing this problem from a software perspective? e.g. Securing the form, having better fraud detection, etc?

    1. 2

      I noticed some weird activity in the past as well. Besides some of the things described here, I forced users to validate their email addresses and to double-check that they are not using throwaway emails.

      This library does the trick nicely.

      But don't forget to update it regularly, since new services for throw away emails appear regularly.

      1. 1

        Useful. Thanks for sharing.

    2. 1

      Looking at Stripe & PayPal's best practice guidelines:

      • Address Verification System (AVS).
      • Card Verification Value (CVV).
      • Contact customers to confirm order.
      • Verify customer identity.

      Probably unpopular suggestions as they add friction but we have to weigh up the risks associated with our own situation.

      Obviously Payment Processors have fraud detection systems but the immediate risk to us are chargeback fees. At $15 a pop they add up quickly, so:

      • Limit purchases (number or amount) from a single account.
      • Daily monitoring + Automated alerts for unusual activity.
      • Refund suspicious payments immediately.

      It would be useful to limit the number of cards used with a single account.

    3. 1

      This comment was deleted 2 months ago.

      1. 3

        One way to simplify the last step is to install the Stripe add on your phone and turn on notifications. It'll notify you about a new customer, subscription or payment.

      2. 1

        This is good advice in general, but how does it prevent automated fraud?

        1. 1

          They need to have user accounts to buy things. keep track of how many cards they have? it needs to be hard for these people to do the automation.

        2. 1

          This comment was deleted 2 months ago.

  4. 1

    I see this as an issue far beyond payment transactions, and it's something that gives me pause to discuss the stack I'm using.

    Fraud is one thing, but defacement for the sake of it happens, and sometimes our products are nothing more than practice for someone.

  5. 1

    I actually have some first-hand experience with this as well. Though thankfully with security in general, not my payment endpoints. Very quickly after my first couple of posts about my current project on Indie Hackers, I was contacted by a "white hat" hacker via email. They said they had identified a security vulnerability in my site and app and asked if I had a bug bounty program as they would disclose the vulnerability to me for a reward.

    My initial reaction was shock and fear, were they trying to extort me? What would they do if I didn't pay, maybe they would attack my site? I thought about it for about twelve hours before replying that I don't have a formal bug bounty but that I would be willing to offer a reward for his effort and negotiated a price that didn't break my budget.

    After agreeing to pay (and getting a bug report that included proof) I fixed the vulnerability, had them verify it was fixed and paid them the agreed-upon reward. I ultimately did not think the reported vulnerability was actually very serious at all, but I figured it was better to just go ahead and fix it and pay them than to set a bad precedent of ignoring these kinds of things.

    However, now I also clearly set a precedent because the same person came back multiple times with new minor reports. After the third time, I realized that even though these were all minor things I might as well go out and use the same kinds of tools that this "white hat" hacker was using and make sure I've hardened everything up myself. I didn't feel like suffering a death of a thousand cuts by having them continue to drip minor reports to me or more concerningly even having someone try to actually find holes to do real damage.

    I'm now pretty paranoid, but I suppose that's a good thing.

    1. 1

      Thanks for sharing. Never going to stop everything but automated penetration testing would be wise.

      1. 1

        Any recommendations? I’m using a trial plan of a Fairly expensive vulnerability scanning service right now but it’s not really a pen testing solution.

        1. 1

          Not really. Tbh was lazy of me to just throw out the phrase penetration testing but we could do with a guide for people to follow. You could start a thread asking for tips + tools perhaps?

          1. 1

            Fair enough, and that's a good idea on making a dedicated thread for it.

  6. 1

    So quick question; what would be the risk when using Stripe Elements, and thus handling tokenized card data? Sure, the stripe element could still be used for automatic card entry, but I suppose they have implemented reasonable safeguards against this?

    1. 1

      Risk is $2.50 per fraudulent API call

      Can't say if example in OP used Stripe Elements but 20k attempts with 3.5k false negatives at $15 each gives risk as ~$2.50 per attempt that hits Stripe endpoint.

  7. -1

    This comment has been voted down. Click to show.

    1. 3

      ^^ Building on top of completely "black-box" 3rd party services is not a secure option. It's an amazing attack vector!

      Even the small blogger with his own vps + wordpress is a target...

      Even? Wordpress is the most popular target because it powers so many websites and a lot of people don't bother updating it on time.

      Imad seems to have no clue about security, he's just promoting he's own serivce here.

    2. 2

      please don't claim no-code solutions are any more secure. Anything written/generated by a 3rd party carries its own risk, arguably greater risks since there is more obscurity.

      The recommendation would rather be to keep systems and software up to date, and follow security best practices when writing code (OWASP does a good job for free to help coders).

Trending on Indie Hackers
How do you decide what idea to work on? 50 comments Design & UI/UX takes me so long- am I doing everything wrong? 32 comments My new self destructing notes app is on product hunt today. Would love some support. 7 comments Looking for feedback on a note-taking tool focused on your personal interests. 7 comments Here's how I'm going to try to scale my tech newsletter from 0 subscribers to 10 000 subscribers 6 comments Bad news for Indie Hackers... 1 comment