Live data from Hacker News

Things to Know When Making a Web Application in 2015

blog.venanti.us

31–40 of 186 posts

Re: Things to Know When Making a Web Application in 2015

#31
Question about JavaScript and CDN for mobile devices. Should I use a CDN for standard libraries or should I just concat and minify all my JavaScript?

The concat and minify seems better as that reduces the JavaScript libraries and code load to a single HTTP request.

A CDN seems nice in theory. Reality is: Does the browser have the library cached? Is the library cached from the CDN that I'm using? The browser is making more HTTP requests, which sometimes takes more time to request than to download the library.

I agree that using CDNs is a good speed boost. I'm trying to figure out if hoping for a library cache hit out weights a library cache miss.

Re: Things to Know When Making a Web Application in 2015

#32

If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…

Security is never perfect. It is a deterrent, not impenetrable prevention. So sure, to security people, it is never good enough. To everyone else, a easy to digest blog post might give them food for thought that would make their work one step better than it was before, resulting in security that is still flawed, but better. So why not just accept the post for what it is - some basic advice to do that one better step.

> So why not just accept the post for what it is - some basic advice to do that one better step.

http://www.nytimes.com/2015/07/10/us/office-of-personnel-man...

Re: Things to Know When Making a Web Application in 2015

#33

One thing to note is login redirect. Please be sure that redirect parameter is local URI and don't redirect user to another site. Maybe even append HMAC signature to that parameter with user IP and timestamp. Might be an overkill, but still be careful with craftable redirects, they might become vulnerability one day.

True, open redirects can cause serious security issues. Do not have an route that simply does the equivalent of `return redirect(params["url"])`, either at login or anywhere.

Re: Things to Know When Making a Web Application in 2015

#34

If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…

Security is never perfect. It is a deterrent, not impenetrable prevention. So sure, to security people, it is never good enough. To everyone else, a easy to digest blog post might give them food for thought that would make their work one step better than it was before, resulting in security that is still flawed, but better. So why not just accept the post for what it is - some basic advice to do that one better step.

If you're going to do something, do it right.

Security is never perfect, and to security people, we know that there is a tradeoff between Security and Users.

We don't advocate letting The Perfect be the Enemy of the Good when it comes to security, and on the same token we want you to implement security properly if you do it.

Re: Things to Know When Making a Web Application in 2015

#35

Question about JavaScript and CDN for mobile devices. Should I use a CDN for standard libraries or should I just concat and minify all my JavaScript? The concat and minify seems better as that reduces the JavaScript libraries and code load to a single HTTP request. A CDN seems nice in theory. Reality is: Does the browser have the library cached? Is the library cached from the CDN that I'm using? The browser is making…

Just to clarify. General CDNs tend to be a good idea of you are having latency issues.

Standard libraries for major JavaScript project, all served from a single shared CDN (like Google, maxcdn, cdnjs, etc) also tend to be called "CDNs" but this is a little confusing. Yes, these shared files are often stored on a CDN, but that's not the so-called major benefit of these shared hosts. The main benefit is supposed to be that, if everyone references the same copy of jQuery on one of these shared hosts, the when visitors hit other sites, jQuery will already be in their browser cache.

This rarely works in practice. The URLs to these shared libraries. Multiple shared services. Multiple version numbers. HTTPS vs HTTP. The net result is that the probability that someone visiting your site has a copy of the exactly same resource referenced via the exact same URL is very low.

With the overhead of having to do a DNS lookup, a TCP connection, TCP slow start, its rarely worth it. Just concat/minify into your own block of JS served from your own systems. Shared JS hosts/CDNs are a terrible and annoying hack, all in an attempt to save 50KB or so

Re: Things to Know When Making a Web Application in 2015

#36
post #16

Earlier quoted context omitted.

I think the OP meant "hash them" with something like bcrypt.

Which raises the question: should you follow web application advice regarding security from someone who mistakenly uses the word "Encrypt" when they (actually or unintentially) mean "Hash?"

Yeah, yeah, I think I would. Someone's credibility as a programmer isn't destroyed in my mind because they say encrypt to describe hashing, especially if they are in fact, hashing and not encrypting and understand why.

This is something I've seen a lot of developers act elitist about, and it's always rubbed me the wrong way.

Re: Things to Know When Making a Web Application in 2015

#37

If you're new to web application development and security, don't blindly follow the advice of someone else who is also new to web application security. You should instead have a security audit with people who have experience in security, so they can help you identify where and why you're system is vulnerable. If no one exists on your team/company that does, then hire a consultant. Security is a hairy issue, and no si…

I wouldnt take any advice on web dev from someone if his simple blog looks like this http://i.imgur.com/uHi0g0Z.png

brb compiling linux to JS to render my blog post.

Re: Things to Know When Making a Web Application in 2015

#38

Earlier quoted context omitted.

Security is never perfect. It is a deterrent, not impenetrable prevention. So sure, to security people, it is never good enough. To everyone else, a easy to digest blog post might give them food for thought that would make their work one step better than it was before, resulting in security that is still flawed, but better. So why not just accept the post for what it is - some basic advice to do that one better step.

> So why not just accept the post for what it is - some basic advice to do that one better step. http://www.nytimes.com/2015/07/10/us/office-of-personnel-man...

Look up "medium-brow dismissal"

Re: Things to Know When Making a Web Application in 2015

#39
First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance.

> If you're just starting out with a new web application, it should probably be an SPA.

Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity.

In nearly every case where an existing app I know and love transitions to a single-page app (seemingly just for the sake of transitioning to a single-page app), performance and usability have suffered. For example, I cannot comprehend why Reddit chose a single-page app for their new mobile site.

It's a lot harder to get a single-page app right than a traditional app which uses all the usability advantages baked in to the standard web.

Re: Things to Know When Making a Web Application in 2015

#40
post #8

Earlier quoted context omitted.

Of course one shouldn't encrypt them, one should salt and hash them. With a cryptographically secure hash such as bcrypt or scrypt. If you use a batteries-included web-framework, this is already done for you. If you do not, you better understand the tradeoff of redeveloping those parts.

I imagine the OP probably meant that and simply wrote the wrong thing in the post. I probably wouldn't have noticed it was the wrong wording if not for this comment chain.

The only acceptable advice in this situation is "use bcrypt". Vague stuff about "hashing or encrypting" is not good enough.
Post reply on HN