It's standard for banking apps to go through all sorts of testing including penetration testing before going into production (here in Paraguay that's how we do it).

That this went unnoticed suggests that:

- the API architect (assuming this web site obtained data via an API, not directly from the database) forgot to validate that requested account belonged to the provided cookie

- the web developer didn't think to test this

- there was either no penetration testing (the author mentioned that this feature was likely released in a rush), or it was not properly performed

...in Norway...

... Also for a specific bank... The title of this article does not reflect the contents.

Yah, this needs a better title.

Changing it to: Tell me your Sbanken bank account no. and I'll tell you how rich you are

Would be enough.

Although I would prefer: Tell me your Sbanken bank account no. and I'll tell you your account balance

We replaced the title with the subtitle.

Submitters: the HN guidelines ask you to change a title when it is misleading or baity (https://news.ycombinator.com/newsguidelines.html). This one was both. When changing a title, please look for representative language from the article itself. Usually there's a subtitle or a first sentence that says what the article actually is.

And much, much larger than just Norway.

I expected the answer to always be "you have no money, I just took it all".

Through just your bank account number?!

In the US, all you need for an ACH transfer is the account number and bank's routing number (which is public info). If the transfer is unauthorized you should be able to get it reversed, but it's still pretty bad.

That is.... Absolutely ridiculous. Why is it like this?

It's a decades-old system originally built on the assumption of trusted participants. It still uses nightly batch jobs to process transfers. Various hacks have been applied to improve it (banks require you to demonstrate some level of trustworthiness before they give you access to make ACH transfers) but that can only do so much.

This is part of the reason why Donald Knuth stopped sending out his reward checks and instead sends a certificate from the fictional Bank of San Serriffe. People were posting pictures of their reward checks, because getting one is pretty cool, which resulted in his account number being published.

A bank account number is all you need to initiate an ACH transaction for any amount to any other account (in the US).

SPAs, client based-REST, and other architectures that expose data/JSON on the Web have probably increased vulnerabilities by an order of magnitude.

Now you've got data moving off of the server that would have normally been selectively parsed/rendered server-side. It's also easy to use marshalling tools/framework features that serialize entire domain objects, which contain sensitive IDs/data that is then inadvertently leaked. You really have two views to think about; one not as visible.

Not to mention, it can take a lot of additional effort and forethought to expose what you need on the client, so that the UI is robust and responsive, but you're not exposing too much.

And, frankly, some devs naively have in mind the common user, 90% of whom couldn't go beyond what's rendered. So, they are falsely comforted by the idea that the data isn't being shown explicitly in the browser.

Ironically, of course, it's exactly the other 10% they need to be thinking about.

I don't think the problem is in architecture. API might be sometimes easier to analyze because it usually has a detailed description, often even in machine-readable form.

> It's also easy to use marshalling tools/framework features that serialize entire domain objects, which contain sensitive IDs/data that is then inadvertently leaked.

This is just poor code quality. Sensitive data can be hidden in HTML attributes and inline scripts too.

The same thing happens when the data is serialised into HTML rather than JSON. Sensitive primary keys get encoded in weird places, like element IDs or class names, even in embedded JS within the page.

"Not as visible" depends on who is looking.

I agree with your premise but filtering fields selected by the database, or serialized into JSON, isn't exactly an unsolved problem. It's probably easier to muck up true... but it's not hard to prevent either.

I would be curious if research confirmed your theory. In my mind with proper layering it makes authentication and what is provided much more clear.

Whatever "dynamically load some JS that loads some more JS that loads the content" thing this page uses doesn't work at all for me on Firefox nightly. Just a blank page with the blog header at the top, even with my blocker disabled.

My work blocks a lot of stuff (apparently including wherever the content here comes from), so I'm having the same problem. It's also common on most Blogspot pages.