3 ms·
In my experience, it’s not been a lack of understanding or knowledge on the devs’ part. It’s been more about how much of a hurry we are in to deploy. I’ve trie
by ianamartin 9y ago
In my experience, it’s not been a lack of understanding or knowledge on the devs’ part. It’s been more about how much of a hurry we are in to deploy.
I’ve tried a few different strategies to get around this.
1. Build the backend first. Don’t show a UI that looks anything like it’s functional until you sneak in the requirements that you know are needed but can’t get buy-in from.
Fails because PMs and stakeholders don’t see progress fast enough.
2. Plan security into the design specs and feature list.
Fails because there’s always someone who (like when presenting speed as a feature) is higher up than you who will cross it off the list because “we’re behind a VPN/our users are too stupid to hack us/the only speed that matters is how fast we can deploy this.
3. Build the entire front end first with absolutely no backend wiring at all and slowly add the connecting db functionality and take your time adding security checks along the way.
This also fails because once PMs and stakeholders see the pretty stuff, they assume it’s almost done and have no tolerance for “slow” progress.
Direct, straightforward communication about the importance of security doesn’t work.
Obfuscating your team’s process to sneak in best practices doesn’t work.
The bottom line is that—again, much like speed—-if your leadership doesn’t see the value or can’t be persuaded to see it, it’s not going to happen, even from very well-educated teams.
This is a cultural issue that an individual contributor can only do so much about by choosing the safest frameworks to start with. And that’s about it.
It’s added a number of items to the list of things I ask in interviews now that I’m on the job market again.
Where does the company prioritize security in web applications? Where does it prioritize speed?
How hard do people have to fight to get these included as product features?
I won’t make a blanket statement that if those answers are not to my liking, I won’t take the job. But you need to know where these things stand as company commitments before you accept a job with a primary role of web developer.
- Sacho 9y ago> 3. Build the entire front end first with absolutely no backend wiring at all and slowly add the connecting db functionality and take your time adding security checks along the way. This also fails because once PMs and stakeholders see the pretty stuff, they assume it’s almost done and have no tolerance for “slow” progress. It sounds like this approach should work, because you can sell a bunch of reasons rather than just security. If you don't take the needed time to develop the code, you will have correctness(not enough testing) and maintenance(not enough refactoring) problems alongside security issues. If the company's leadership shuns all three in favor of quicker deployment, then security is most likely not going to be the biggest problem, it would be all the bugs you have to chase down in spaghetti code.