15 ms·
Web Developer Security Checklist
- dbg31415 9y agoThis is great! Unfortunately this old list hasn't been updated in forever: * Web Developer Checklist || http://webdevchecklist.com/ http://webdevchecklist.com/
- iovrthoughtthis 9y agoImplementation discussions for each of the checks would be handy for those of us not familiar with all of these practices. Also those most likely to need such a list.
- aeronautic 9y agoGreat idea for a follow on post. I'll do that.
- appcraf8 9y agoHow about extending the same with examples for popular web frameworks like django RoR?
- aeronautic 9y agoI know node better and would be a bit light on other frameworks. Do you have suggestions?
- appcraf8 9y agoThrow across your node work. I will try to replicate the same for RoR. :-)
- aeronautic 9y agoWhen I post the implementation notes for Node, feel free to speak up with the RoR speak for that item and I'll add it in. Thank you.
- ianamartin 9y agoI'd be happy to try and do a Python version of this. I'm most familiar with Pyramid, but Flask and Django would be a learning opportunity for me. Much of this advice I've already implemented in Pyramid.
- ianamartin 9y agoI'd be happy to try and do a Python version of this. I'm most familiar with Pyramid, but Flask and Django would be a learning opportunity for me. Much of this advice I've already implemented in Pyramid.
- iamdave 9y ago"Hack yourself" May I suggest the opposite, and say if you're going to pen test your infrastructure, don't have the same people maintaining the infrastructure trying to hack the infrastructure.
- aeronautic 9y agoDo both. I'm a big believer in having dev learn and own a part of the security process. You learn an enormous amount by hacking yourself. But you are right, you definitely need other eyes to pen test as well.
- iamdave 9y ago>Do both Actually yes, this. Good call out.
- FLUX-YOU 9y ago>Do both. I'm a big believer in having dev learn and own a part of the security process. Devs already do enough, take some bloody ownership of security outside and inside of code. When devs start having to whiteboard security issues in interviews, then you can make us responsible for it because we'll appropriately charge you for being decent at two things instead of one.
- eropple 9y agoThis is...shortsighted. Security is part of your development work. It always has been, always will be. You need to understand application and server-level security--the former is always your responsibility and while you may have specialists for the latter they do not replace you understanding the fundamentals of it. The server is part of your "stack", even if the "full-stack" people want you to believe it ends at the language runtime. If you are a web developer and in your interviews you aren't demonstrating that you can think in a security-conscious way, your interviewers need to reflect.
- FLUX-YOU 9y ago
- jaequery 9y agoNot simple by any means, this one is very thorough and one of the better security checklist I've come across in a while! Sensedeep looks very intriguing and I often wondered if anyone has created an alternative to Atomic Secured Linux. Could this be it? Or is it like an ids / ips with a gui?
- aeronautic 9y agoWe're just in beta. SenseDeep is part host-IDS and part cloud-side. The key is real-time. We want to detect attacks in real-time on the server or on the cloud-side. It has a GUI on top to unify and give a cloud complete view. The focus is DevOps and not companies with a security team. Not sure if this helps or confuses things.
- jaequery 9y agoDoes your product help satisfy any areas of the pci compliance?
- aeronautic 9y agoI don't want to take the focus off the post and discussion which was about the web checklist. You could dm me twitter @SenseDeepSec or email mob. But briefly, we hit some of the PCI compliance objectives but not all. We expect to cover more ground in this regard quickly.
- sho 9y agoWhile it means well, I think some of this advice is pretty bad, or at least unbalanced. From the very first section: > Encrypt all data at rest in the database ALL data? How are you supposed to query against it then? What does "at rest" even mean in the context of an always-on database? An encrypted partition or something? I'm not even sure what this is supposed to mean and it is certainly not common practise. > Use secondary encryption for data identifying users and any sensitive data like access tokens, email addresses or billing details So two layers of encryption!? Again, how is one supposed to look up an access token or email address if it is encrypted? And it strikes me that if you don't trust the first level of encryption, the solution is to fix that, not add another one. > Fully prevent SQL injection by only using SQL prepared statements and stored procedures That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries. I could go on. The costs of implementing these recommendations would be staggering for the questionable benefits they would provide. It is absolutely possible to have excellent security without implementing any of these ideas, and I don't think they're helpful at all - and certainly not "simple".
- xupybd 9y agoTotally with you on the DB encryption but I'm not sure about your comments on prepared statements >That is an extraordinarily inefficient and costly way to develop. The correct way to protect against SQL injection is to use a framework/driver which guarantees escaping and to be cautious about what you allow into queries. I've always found using only prepared statements is feasible and justifiable. What is about using them that adds to cost and inefficiency? Prepared statements are not a silver bullet. Somethings like limit statements in mysql are very hard to do with prepared statements but for the most part it's a good rule of thumb.
- sho 9y agoMy apologies - my brain focussed on "stored procedures" and that's what my rant was addressing. Prepared statements are great and I'd use them whereever possible - totally agreed.
- xupybd 9y ago> Create immutable hosts instead of long-lived servers that you patch and upgrade. (See Immutable Infrastructure Can Be More Secure). An interesting idea, I've not come across before. Anyone know where I can find some case studies on this?
- aeronautic 9y agoI did a post on that here: https://simplesecurity.sensedeep.com/immutable-infrastructure-can-be-dramatically-more-secure-238f297eca49 https://simplesecurity.sensedeep.com/immutable-infrastructur... but the originator was: Chad Fowler http://chadfowler.com/2013/06/23/immutable-deployments.html http://chadfowler.com/2013/06/23/immutable-deployments.html
- eikenberry 9y agoNetflix is notable for doing this with all their infrastructure. You could probably find some presentations by them about it. Martin Fowler wrote about it, so that would be a good place to start. https://martinfowler.com/bliki/ImmutableServer.html https://martinfowler.com/bliki/ImmutableServer.html
- horsecaptin 9y agoHow much of this is built into various frameworks such as Rails, Django, EmberJS (for frontend) etc?
- aeronautic 9y agoNo much at all.
- sho 9y agoFor RoR many of the app-level points are - CSRF, SQL escaping, bcrypt by default, etc. That's a big reason to use such a framework in the first place.
- creepydata 9y agoYeah, what kind of shitty frameworks is this person using if the answer to this question is "not much at all?"
- ozren1983 9y agoDjango actually has pretty good out of the box security settings and support for XSS, CSRF and SQL injection protection, support for bcrypt and argon2, setting password rules/validation through settings, etc: https://docs.djangoproject.com/en/1.11/topics/security/ https://docs.djangoproject.com/en/1.11/topics/security/
- palimpsests 9y agoEmberJS handles all the aspects that purely browser-based application code can - protecting from XSS attacks, setting up your Content Security Policy, and client side input validation.
- cyberferret 9y agoHope the moderators edit the post title to include that this is a 'security' checklist, and not just a 'steps I need to develop a simple website' checklist. I am thinking quite a few people skipped past this article not realising the intended audience.
- michaelmior 9y agoAgreed. The original title of "Web Developer Security Checklist" is much better.
- tptacek 9y agoThere are 168 comments on this thread all earnestly discussing what is pretty clearly a marketing document written by someone without a firm grip on most of the bullets they've written. Is there that much of a need for another "security checklist", that we'll dive in this deep on a really bad one? Seriously asking! Finally: if you're worried about "APTification" or whatever it is this company is talking about, and you're deploying in AWS or GCP, do what Ryan's team at Slack did and get auditd monitoring on all your servers, and perhaps get osquery instrumentation set up as well. Attack detection systems like the product this post sells are pretty far down the list of things you should be considering.
- aeronautic 9y agoAs the author, I should clarify that I am a developer - full time and have been for years. If my english seems to imply a lack of depth of understanding - I'm sorry. The purpose of the checklist is to get people thinking about items they may have forgotten to address during their dev. In the push to ship new products quickly, that happens all too often. I agree with you that there are many more important and basic things to do first when securing your app - than worrying about APTs. I did not think the checklist gave that impression?
- wglb 9y agoEnglish is not the problem. You are missing fundamentals like the Seven Deadly Sins of Web Security. Also missing is ninja threat model. These are the thing that will wipe you out.
- nnaumann 9y agoSimple Web Developer Checklist: #1 make sure the css stylesheets are loading
- slackingoff2017 9y agoI like this better
- partycoder 9y agoA largely incomplete list. One of the most important items would be: handle errors correctly and make sure errors do not result into any sort of resource leak or sensitive information disclosure. For example, this code was from a guy in Stack Overflow: ... function (req, res, next) { if (err) return console.log(err) What will that piece of code do? Leak the request object, the response object, including the underlying client connection... keep the connection open, leak memory... and at scale, make your server run out of sockets and memory. Then, when memory is low, swapping kicks in, overloading your CPU as well. In short, kills your machine with only a little 1 line of code mistake. There are less trivial ways of running into the same situation, but the lesson is that node.js is not a babyproofed technology and needs to be used with care. This piece of advice is one of the most important, and the most overlooked/ignored in the node community.
- Kiro 9y ago> make your server run out of sockets and memory Do you mind explaining why the code causes this?
- partycoder 9y agoBecause when you handle a request, you need either respond to it or close it. If you don't close it (e.g: res.end, res.send, ...) the connection remains open. Also all the memory allocated for that request stays around without being collected.
- aeronautic 9y agoAgree with the point, but remember normal HTTP/1.1 /2 keep alive should close that connection in 15-30 seconds for all modern browsers. It will give rise to a DOS vulnerability as you point out.
- partycoder 9y agoBut all the objects remain leaked even if the request connection ends. And if the request stream got piped into another stream the problem can become more severe. Usually error events propagate through piped streams, but that largely depends on the order in which the event handlers were defined.
- omegaworks 9y ago>Use... CloudFlare. lol
- ry_ry 9y agoWhy lol? Not being a douche - I'm genuinely curious why that is a laughable suggestion.
- Animats 9y agoCloudflare MITMs your secure connections. If you get the cheaper Cloudflare options, it's really insecure.
- aeronautic 9y agoYes it does that and that will rule it out for some apps. An option for many sites is to configure CloudFlare in pass-through mode (no MITM) and then just switch it on when you are being DOS'd.
- corobo 9y agoIs that even an option? Where is that setting?
- aeronautic 9y agoThat is the cloud icon. Make it gray and it is just a DNS. i.e. DOS protection armed and ready, but not active until you need it. That is how we use it.
- corobo 9y agoAh I see, I thought there might be a setting I'd missed that just forwards your traffic through without cache etc
- aianus 9y ago
- strictfp 9y agoThis list could just as well be called "List of security stuff I learned about when making my product". Some of the stuff is just Draconian, certainly not applicable for any arbitrary web developer.
- viraptor 9y agoThere are rarely any checklists applicable everywhere in the same way. Why not treat it as: list of ideas to evaluate and prioritise/ignore into your own checklist for future/current project? It's not like it's all invalid because it's not fully applicable.
- strictfp 9y agoNo, I think it's valuable as a work log and bucket of ideas on how to improve security. It's just how it's framed that irks me.
- Kiro 9y agoWhen do we get a SaaS which just comes with all this built-in? I want to pick a framework and let the service add all these things, including automatic updates.
- wiz21c 9y agothis.
- eropple 9y agoWhat you want, and what is effective and feasible, are at odds. Trying to build a framework for this to work in the general case will--not may, will--result in something that doesn't work in that general case for anybody. You can't framework away security. Parts can be abstracted, but that abstraction is for ease-of-use, not correctness; you need to understand what's going on and why. It's your job to. (Or pay someone else to. But we're expensive.)
- aeronautic 9y agoI agree with you, but I understand his wish though. Security sometimes is just hard and it is unrealistic to hope that all developers, everywhere, all the time will get it right. The more the platform can do, the better.
- eropple 9y agoI understand it too, but it's, to be honest, horseshit. Well-meaning horseshit, but horseshit despite it. Security is hard. It is irreducibly hard when you add the constraint that arbitrary do-whatever code and applications must be supported. Having your platform do things is great--to make you faster. You still have to understand what it's doing because it's very easy to step outside the guarantees of that platform and suddenly no longer benefit from those security features. Sometimes you might even have to do that for business reasons. And then you must know how to safely compensate for it. It's a rare web developer who isn't safeguarding somebody else's personal information. (Yes, even just name + email. Don't make it easier for other people to be phished.) The onus is on us as a development community to take that seriously and to treat the security of our code and our systems with the caution it mandates.
- xanderjanz 9y agoApparenlty written by somebody who isn't responsible for the actual web development themselves, just upfixed web devs work for enterprise pen testing.
- aeronautic 9y agoSorry, not true. Spent many years doing full stack web dev and security. Please offer some constructive criticism - gladly received.
- softawre 9y agoYou are the OP HN needs but not the one we deserve...
- systematical 9y agoStopped reading at "Encrypt all data at rest in the database" Not sure who this guy is, but are you fucking serious?
- jwr 9y agoI do not like this list. > [ ] Use minimal privilege for the database access user account. Don’t use the database root account. This advice seems outdated. In general, every significant security breach will get the attacker root access. Playing games with database accounts gets you no security at all, while introducing lots of friction and headache.
- spydum 9y agoSorry, you don't throw away mitigation techniques because they aren't foolproof. This is still excellent advice. Stop using sa and root accounts for your apps.
- retro64xyz 9y agoI agree with Spydum. The reason I agree is - Layers of security are required. You should not use a root account for your web application. You should also use escaping, properly formed queries, and prepared statements. You use best practices in an orderly manner and you will be much safer than just picking one "silver bullet". Not every attack provides root access to the database or server. Why make it easier for folks? Least privilege is a viable tool in your bag.
- deno 9y agoSignificant breach in the context of web development is usually logic error that leads to unauthorized application-level access, leaking cookies, service unavailability etc. This is however not the most likely thing to go wrong, in general. Topping the charts is as always, the one and only, User Error! Restricting db access is the last line of defense against accidentally DROP-ing TABLE in production.
- slackingoff2017 9y agoBesides the bad SQL tips most of it is okay. Sounds like the author has little experience with ORM's or SQL abstraction layers with parameterization like ADO.NET, SQLAlchemy, or JDBC. Besides the SQL stuff mentioned elsewhere, Regex is rarely a safe whitelist. It's better to use specific escapes for HTML or URI or whatever. Most of XSS is finding bad input that isn't filtered. Hardly anyone is stupid enough to not filter input at all, but few filter it enough to prevent all XSS. Also keeping port 22 closed is just silly. If you have secure credentials no amount of portscanning will hurt you. If you get tired of the logs just move the port and setup fail2ban. This point is controversial so whatever I guess.
- aeronautic 9y agoThanks for the tips. Can you say which SQL tip is bad, someone has already picked up the Stored procedure comment -- really meant prepared statements. Regarding regexp. You can do very precise regexp for many patterns. I agree some are harder, but I wouldn't say "rarely" in our experience. The point about port 22 is that if you have it open, many people tend to use it more than they should. Effective automation should eliminate / greatly reduce the need for it. If using AWS/cloud, then you can apply a security group to open when you need, but otherwise keep it closed at the network level at least. I agree it does seem to get people all hot an bothered.
- slackingoff2017 9y agoA lot of Regex is a hint that you shouldn't be using regex. Regex is a bad parser and poor sanitizer. I would wager that more than 50% of XSS vulnerabilities are due to bad regex when you should be using HTML or URI escape
- _cereal 9y agoHi, about port 22, you can use ssh keys and disable password access, see: https://aws.amazon.com/articles/1233/ https://aws.amazon.com/articles/1233/
- chvid 9y agoLots of random mostly unnecessary advice that will surely take a simple project and turn it into a big half-baked unmaintainable mess. Sorry for the harsh words; but good advice needs to be both practical and cost-efficient.
- aeronautic 9y agoCould you highlight what you think are the important items in a web security checklist?
- slackingoff2017 9y agoCome on man, 4 submissions in 5 days all leading to your startup's website? And a profile created 5 days ago with zero comments on anything you didn't post? You could at least try to make it look like you're doing more than promoting your startup.
- aeronautic 9y agoBeen an avid HN reader for ages, but been seriously heads down doing the startup thing for about a year with zero time for blog or posting. Insane hours. Started surfacing a month ago so I can do more than just code and wanted to share a bit. Not trying to hide the company, in fact pretty proud of it and the new things we're doing. But we are very early stage and still in beta. I do want to add value through the posts and discussion like this regardless.
- andrewstuart 9y agoI never heard any rules about these things. If this character is coming up with worthy content then who cares? The vast majority of blog posting is indirect (or direct) marketing. I don't think he's done anything wrong.
- valar_m 9y agoOP's submissions appear to comply with all of the site guidelines. What does it matter if they also happen to send traffic to his startup?
- winut23 9y agoIsn't best practice when it comes to passwords to actually choose a good one, use a password safe, and _not_ rotate?
- aeronautic 9y agoBoth. You want to choose a good password and then not let it get too stale. A very old password (say 1 year) has a higher chance of being subverted purely because there is more elapsed time wherein attackers could have gained access. Choose good passwords, long, special chars, preferably random and generated by a password generator / manager. And then change periodically. That period depends on your application. We change our cloud passwords and keys every 90 days.
- rubidium 9y ago"A very old password (say 1 year) has a higher chance of being subverted purely because there is more elapsed time wherein attackers could have gained access." Any actual evidence for this? My counter-hypothesis is if your password lasts 6 months of attempted hacks it'll last >6 years (unless social engineering attempts succeed). I ask because rotating goes against the current NIST password guidance. In fact, for your recommendation "Implement simple but adequate password rules that encourage users to have long, random passwords", I'd recommend pointing people in that direction.
- aeronautic 9y agoSorry, I should be clearer (late here). With time passing, the chance of you or anyone with access to the password being socially engineered, or some other human error, or a hack on your PC desktop systems, increases linearly with time. The password may last a decade of brute force cracking, but we humans .... continue to make mistakes far more frequently. So rotating passwords protects against the accumulation of human mistakes and insider threats. If you are using proper hashing, then your passwords should be safe even if the hashes are compromised. Could you please point to the NIST recommendation you mention. I thought they said that you should NOT force customers to change passwords. But that is different to you rotating your own critical passwords at a time of your choosing and on your policy.
- smoyer 9y agoOWASP has published a release candidate of the OWASP "top-ten" available as a PDF at https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2.... They also support the creation and maintenance of quite a few OSS tools to help secure systems. To those who are claiming some of these steps are too onerous or would cause performance issues: Are you sure? For an individual system, maybe some of these checkboxes are indeed overkill. Or perhaps your system isn't as secure as you believe? To be fair, there are systems that don't require as much security because the data simply doesn't matter - if they systems contain email address / password hash combinations, they should still treated very carefully. I think the biggest mistake I've seen made time and time again is that teams go the cheap route and put the database on an Internet connected machine. Don't build a whole architecture until you've got customers to support it but don't be quite that cheap at the beginning. For systems that require higher than average security, I've been part of a team that went to MUCH further extremes.
- hartleybrody 9y agoCan you elaborate a bit more detail around a MVP-style architecture where the database isn't on the public internet? I assume you're talking about something like a public facing load balancer that connects into a private network where the web servers and database server live, and you'd need a bastion host (or just the load balancer) to connect into the private network and access any of the machines.
- smoyer 9y agoYes ... that's about the simplest form. If you want to get really fancy you can use a further cloistered machine with hardware encryption and a key that's only inserted when the machine is booted but that's pretty excessive. The main thing is that you don't want your database server's port exposed to the Internet and you don't want your database on your web servers (the most likely part of your infrastructure to be compromised).
- nolikeynovotey 9y agoThere's some good Android & iOS security checklists here - https://codifiedsecurity.com/2017/04/24/mobile-app-security-testing-checklist-android/ https://codifiedsecurity.com/2017/04/24/mobile-app-security-... & https://codifiedsecurity.com/2017/04/19/mobile-app-security-testing-checklist-ios/ https://codifiedsecurity.com/2017/04/19/mobile-app-security-...
- vultour 9y agoPrepared statements are amazing. Found out about them very soon after I started programming (incidentally my first language was PHP), and switched to PDO right away. This was years ago, I don't understand how people are still using the deprecated and insecure mysql_* functions, you can still find them all over SO and my university "web" class was teaching them as well...
- plug 9y agoYou'll be glad to hear that they've finally been removed since PHP 7.0 so slowly but surely they're being consigned to history. And there seems to be much better awareness about the perils of mysql_* functions amongst PHP devs these days. However, 5.6 is still in security support until 31st December 2018, so all that bad advice on SO and elsewhere is still relevant and lurking, waiting to be found by inexperienced devs.
- flukus 9y agoAs other people have noted, prepared statements aren't a security panacea, and string concatenation you do in the query can be vulnerable.
- pjmorris 9y ago"Finally, have a plan" I'd argue that you're more secure and your life is easier if the plan (threat model), or at least the planning, come first. The greater your understanding of your data, users, platform, and attackers, the more likely you are to make good (e.g. secure, economical) choices about infrastructure, design, implementation, testing, incident response, etc. "Plans are nothing; planning is everything." - Dwight D. Eisenhower
- EGreg 9y agoI would add one more regarding DOS protection: Sign the session tokens that you issue. This way you don't need to do any I/O to verify these tokens at the router level.
- aeronautic 9y agoI'm not sure I fully understand what you are saying. Can you elaborate.
- EGreg 9y agoI came up with this technique when designing our platform (https://qbix.com/platform https://qbix.com/platform) so I don't know if it's widely used. Many apps include session id tokens in requests, to identify the logged-in user. The session id is usually a bearer token (like in a cookie) which identifies the session on the server. To mitigate against DDOS attacks, as you said, all publicly available resources can be cached on CloudFlare. (Personally I look forward to content-addressable protocols like IPFS supplanting HTTP.) However, the non-public resources are usually dynamic and should not be cached. These resources are typically for users who have logged in, or at least have a session. So our design basically encourages this: 1) if you want to serve non cacheable resources, require that the request included a session id 2) the session id is generated on our server and signed with an HMAC so the app can verify this signature without doing any I/O. This is because I/O is expensive and hard to parallelize, whereas statelessly checking whether a session token has been issued by our app is easy to implement, even at the external router level. Simply examine the packets coming in, decrypt, look at the request, and verify the HMAC on the session id. If it is wrong then the session id is bogus so we don't expend any more resources within the network on this request. You can make sessions expensive to start. For example, a user might have to log in with a valid account to get a session. The big question is, how can we ensure that users don't get too many accounts? To prevent sybil attacks. Any ideas?
- spydum 9y agoIt is shocking to me to see how many developers giving this checklist a hard time. Every single item is solid advice and what I would have presumed sane people considered common sense/best practice. Just goes to show how bad a job we have done in the InfoSec world of educating developers.
- ams6110 9y agoI got downvoted in another reply, but "security by checklist" was one of the biggest complaints that SANS and other security firms had about enterprise and government IT security policies. Not that it's a bad checklist, but most "web developers" will not have the background to understand and implement all of these things properly, even if they think they do. Security is not a checklist -- "OK, all boxes ticked, we're done" -- it is also an ongoing, reactive and proactive set of processes and constantly re-verifying that everything you think is so, is actually so. And if you rely on "web developers" to get all of this right you will at some point be disappointed.
- aeronautic 9y agoI think we can all agree that developers can get better educated about security and can participate building security into the product from the very start. It is hard to engineer security in via a sec-team at a later stage. Education is the key.
- creepydata 9y agoHow is something like "Use CSP without allowing unsafe-* backdoors" in any way educational? If I'm a newbie web developer, even coming over from embedded systems, how do I know what CSP is? What do I use CSP for? How do I start with CSP? What do I do to configure CSP? What does CSP even stand for? I don't know, it wasn't even defined! Basically, this is a useless listicle. If you know anything about web security you get nothing from it and if you don't know anything about web security you still get nothing from it.
- 9y ago
- Gmo 9y ago@aeronautic, there's a typo on your website front page : "acccount" with 3 c.
- ryandrake 9y ago> Store and distribute secrets using a key store designed for the purpose. Don’t hard code in your applications. Curious: Is there a widely-used off the shelf solution/pattern for this? Or a "idiot's guide to writing one"? It's always seemed to me like super bad practice to hard-code a (for example) AWS secret into your app. However if you set up a basic web service to deliver the AWS secret to the app, wouldn't your app need to authenticate with that service with... a hardcoded secret?
- ams6110 9y agoSure, classic chicken and egg problem. At some point you need an unencrypted secret.
- eropple 9y agoA better way to phrase it is that at some point you need trust. AWS IAM instance profiles are a great example of this.
- ad-hominem 9y agoI always use environment variables, you can just use ENV['AWS_S3_KEY'] or whatever in your application code. Keep the keys in your local environment, and add separate sets of keys to the staging / production environments. These files probably live in your project (.env or similar) in development but are gitignored. On production, they can be in your web-server or application configuration wherever appropriate, as long as they get loaded. If you are using a tool to manage deployment, you probably just need a step to verify on deploy the files / lines containing keys exist. I can't think of a widely-used programming language that doesn't support environment variables, though support may be less than exemplary in your language of choice. In ruby land, I use https://github.com/bkeepers/dotenv https://github.com/bkeepers/dotenv
- ryandrake 9y agoNot sure how storing the secret in the user's environment helps. At the end of the day, you're still distributing a secret to an untrusted end user.
- ams6110 9y agoForgot one: [ ] Don't rely on security-by-checklist.
- adakbar 9y agoIs it good to redirect to https when user hit API with http? I have heard somewhere doing so is bad
- SadWebDeveloper 9y agoNop.. it isn't good, secure endpoints for API's shouldn't be exposed in plain, an error should be raised when a developer/app tries to contact via HTTP rather than HTTPs.
- thatwebdude 9y agoIs 404 sufficient?
- SadWebDeveloper 9y agoDepends on your choice, personally i would choose between 410 or 501 but whatever you choose, just don't allow an implicit redirect with any of the 301/302 codes.
- max23_ 9y agoCorrect me if I am wrong but even with https redirect, POST request will fail though.
- SadWebDeveloper 9y agoGeneral guidance mostly, nothing too deep, seems suited for C-level since there is no discussion on securing the infrastructure (as in hardware, not in software), deployment and way too heavy on looking at the world "from the clouds".
- eggbrain 9y agoMy biggest worry with this checklist is that while it helps already security-minded people and web developer professionals remember what they should already be doing, it doesn't really help security novices (who may search for something like this) make their app more secure. Why? 1. The checklist tells me what I need to do, but not how to do it right. I could imagine many security novices reading one of these items, implementing the first solution they find on StackOverflow, and checking it off in a "fixed it, boss" kind of manner. That may lead them to thinking their app is more secure than they should, and is then a detriment to the security of their app. 2. The checklist doesn't really help me decide in what order to do things, and what perceived increase in security I'll receive Storing sensitive data in the database using bcrypt is pretty easy to implement (many times baked into web frameworks), and provides a good amount of security for the time it takes. Compare that to something like implementing CSP however, which may involve moving a ton of files around your app, adding nonces/hashes, etc, and it gets me an A+ on secureheaders.io, but I'm not sure if all the pain was worth it for my basic application. 3. The checklist makes things way harder for a developer to think about. Anyone wanting to build a web app looking at this list would probably be too overloaded with information to want to implement much of this, when in reality, they could start off with something like Heroku where they just push it up and it works, and many of the security concerns have been taken care of for them.
- aeronautic 9y agoThanks for your well structured comments. The purpose of the checklist was to get people to think. It is really hard to do much more without going very long. A number of people have suggested that I link implementation background off each item. I think that can work and layer the info as well.
- eggbrain 9y agoI know your pain -- things like this get long fast, and it's hard to include everything all at once without going on forever. I would definitely appreciate implementing some background off of each item! Another thing that might help is knowing about services or open source solutions that can bundle a lot of the checklist together. Heroku might be a paid one, for example, but there might be things like ansible scripts out there that do a lot of this from security professionals, I'd love to know how to be able to package a lot of these checklist items together more easier.
- aeronautic 9y agoThanks everyone for some great comments and discussion. Really appreciate your time and feedback on the article. I'll fold in the feedback and the ideas and go forward with it. Thanks all OP: Michael O'Brien
- type0 9y agoSecurity is a process and not a product of some checklist.