[HN Gopher] Probably Are Gonna Need It: Application Security Edi...
       ___________________________________________________________________
        
       Probably Are Gonna Need It: Application Security Edition
        
       Author : pcr910303
       Score  : 54 points
       Date   : 2021-07-29 12:44 UTC (10 hours ago)
        
 (HTM) web link (jacobian.org)
 (TXT) w3m dump (jacobian.org)
        
       | tpmx wrote:
       | > it's nearly impossible to retrofit mitigations for spam,
       | harassment, or abuse
       | 
       | ... why?
        
       | simonw wrote:
       | I really like Jacob's suggestion to set up the "restore a copy of
       | the production database to staging" script to use an allow-list
       | of columns, rather than a deny-list.
       | 
       | It's so, so easy for PII and other sensitive data to end up
       | copied to a staging environment, which has a higher chance of
       | shipping a security vulnerability than the production environment
       | does (plus exposes data to staff within an organization).
       | 
       | Strictly allow-listing columns from the start seems like a great
       | way to minimize accidental leaks.
        
       | egberts wrote:
       | It is bad enough that I have had to apply "application-layer"
       | security to systemd in order to ensure that it "behaves".
        
       | wepple wrote:
       | Get your AuthZ design right early on, or you'll forever be
       | plagued with APIs that fail open or aren't protected, and it's so
       | very hard to change later on.
       | 
       | The best advice I've seen on this:
       | https://research.nccgroup.com/2020/04/21/code-patterns-for-a...
        
       | 3pt14159 wrote:
       | This is a great list.
       | 
       | I think one of the hardest things to add after the fact are
       | security headers. Once marketing is involved with an app's
       | marketing site, it's going to be hard to add them in later. So I
       | add them from day one, ace the Mozilla Observatory thing, and
       | then if marketing needs something special, we can always deal
       | with it then. Usually the result is something more secure, but
       | sometimes turning off a flag for a single page is fine.
       | 
       | If it's the style of app where the backend is basically just a
       | JSON API + workers, I like to follow JSON API[0] but I always add
       | the `meta` and `errors` fields, even if it's just an empty dict,
       | but usually there is something meta, like the latest versions of
       | the client and server or a rate limit use + available combo. It
       | makes writing clients easier. It also has knock-on effects, for
       | example a delete request never gets a 204 NO CONTENT, since there
       | is always content!
       | 
       | Once you get a consistent API the frontend just snaps together.
       | Every now and then you may have to deviate a bit for performance
       | or third-party reasons, but it's fine.
       | 
       | [0] jsonapi.org
        
       | wepple wrote:
       | Password hashing. Because you're not storing clear text
       | passwords, it can be tricky to upgrade later if you've chosen
       | something bad like md5. You either have to force your entire user
       | base to reset, or you do an over-time migration when people
       | login, which will always leave some not upgraded.
        
         | tpmx wrote:
         | That's a much better suggestion that most of the points in the
         | article, IMO.
        
       ___________________________________________________________________
       (page generated 2021-07-29 23:00 UTC)