Comment by codingdave
3 days ago
> Leave it be until I need it seems like the right answer
That might be correct, but knowing what moves you intend to make if a problem occurs is wise. For example, suppose you wake up one morning to find that your site was flooded overnight with content that is illegal. If you already had a plan in place for problematic content, you execute the plan, instead of being in a high stress situation and being forced to research and make quick decisions on the fly.
In theory I start integrating some safe image api or something, but I'm not seasoned enough to know if scrubbing the data away manually then is going to be easy enough. Right now I use supabase email auth , and I figure that cuts things down somewhat.
And if I am to have a plan, why not just implement from the start?
Risk management is not (always) about prevention as much as it is about reaction and mitigation.
Most nefarious attacks on sites/apps are occasional or one-time things. As an example, I used to work on a site that would get DDOSed a few times a year. I'm not sure why we were targeted, but rather than move our entire weird old legacy infrastructure to a vendor who could mitigate DDOS attacks, we had standard actions to take: Call our server dude, roll traffic to the backup data center, id the IPs at fault, add them to our block list, inform partners and customers to let us know if the new IP blocks affected them.
It was an annoyance, but not a disaster. That is the level of preparation you want - enough to just be annoyed when bad things happen, not demolished.
That should not stop you from prevention, either, of course - if you want to be proactive about such things, go for it.