[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1792098442564.jpg (208.66 KB, 1024x1024, img_1792098433865_40jbe587.jpg)ImgOps Exif Google Yandex

86ed5 No.2342

been thinking about this all morning because i just saw another dev trying to patch cors after the api was already live. it's so exhausting watching teams treat security like a layer you just slap on top of existing code once something breaks. you can't just add it later without breaking everything.
>Security isn't something you add to software. It's something you build into it from the beginning.
it's much easier to handle things like encryption standards or field-level masking at the domain layer before the first pull request even exists. if you aren't doing threat modeling during architecture, you're basically just waiting for an incident report to hit your inbox. i don't know how anyone manages to maintain a clean pipeline when they're constantly chasing vulnerabilities in production. it feels like people think 'secure by design' is some magic trick instead of just basic engineering discipline. it's actually just common sense but nobody wants to do the extra work upfront. does anyone here actually get time for a proper threat model before shipping, or are we all just winging it?

found this here: https://www.freecodecamp.org/news/secure-by-design-engineer-security-into-architecture-before-writing-code/

86ed5 No.2360

>>2342
>if you aren't doing threat modeling during architecture, you're basically just waiting for an incident report to hit your inbox.

seen this happen with a recent migration where they forgot to audit the s3 bucket permissions until we were already leaking logs. its way easier to just fix the iam policy before the deployment goes live than trying to clean up a mess after the crawler finds it.
it was literally public

86ed5 No.2366

>>2342
>>2360 s3 buckets are such a disaster waiting to happen if you don't lock them down early. i dealt with a client last month who had an entire directory of sensitive user uploads set to public because someone wanted to bypass the auth middleware for a quick test and just forgot to revert it before prod.



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ Home / About / Contact / WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]