3

Are there any added security risks that come with using a 3-tier architecture such as MVC in a software project?

I got asked this today, and my gut reaction was "I don't see why there would be." After some consideration, I decided that I don't actually know the answer. I took a look at another question, but it didn't really have any useful information.

Ideas?

Community
  • 1
Polynomial
  • 132,208
  • 43
  • 298
  • 379
  • As opposed to what model, or just in general? – GdD Oct 04 '12 at 12:22
  • Just in general. – Polynomial Oct 04 '12 at 12:28
  • 2
    If I may pick a nit, MVC isn't a 3-tier architecture. To quote Wikipedia "the three-tier architecture is linear, the MVC architecture is triangular". – David Wachtfogel Oct 04 '12 at 17:48
  • @DavidWachtfogel Heh, I guess that's technically true, but that's the first time I've heard someone say MVC isn't 3-tier. As far as most people are concerned, an architecture with 3 sections that are linked in a constrained way is 3-tier. But anyway, the definition isn't important. – Polynomial Oct 05 '12 at 07:27

4 Answers4

4

My gut feeling is that the MVC model, or, for that matter, any cleanly defined model, tends to decrease security risks. Although things are not that clear.

From a very general point of view, security issues are a special kind of bug, on the implementation or on the structure (possibly the specification). Knowledge dilution is a huge risk factor: bugs happen more often when there are more people involved in the project. To keep the whole thing secure, there must be someone, at some point, with a transverse view of the project, who can think architecturally and grasp the interactions between all the modules; this becomes harder when the project size grows. To say things in plain words, for a secure Linux kernel, you need a Linus Torvalds: one head who receives all the information.

Any clean model which defines the roles and tasks of sub-modules in a clear way, such as the MVC architecture, will help that one-thinking-head a lot. It makes it possible to maintain the necessary project-wide security thinking framework, when the project becomes huge. On the other hand, the MVC model encourages throwing more developers at a project, which mechanically increases security risks, so MVC is a mixed blessing.

As a basic rule, the smaller the project, the more secure it can get. The Lone Wolf Developer model will get you more secure applications, and probably will deliver them faster, but with less features.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • +1 for knowledge dilution. In theory, a well-architected three-tier app, with the exact roles of each tier explicitly documented, could be a security benefit. In reality, what tends to happen is that team A think component B will be doing an authorisation check, and team B will think that component A has already done it, or some combination of corner cases on each component will result in a path that goes unchecked... – bobince Oct 05 '12 at 17:33
2

In slightly different words to Thomas:

You do potentially increase the attack surface any time you increase the number of devices, layers, roles, developers purely as you have more variables.

That said, you do at least have a framework which should ensure that security issues, including those brought by a more complex structure, are identified and managed.

On balance you should be able to reduce vulnerabilities, risk and remediation costs through an MVC type architecture.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
0

Some history

The 3-tier architecture model is actually a "communication model", not a software model: the browser talks to a server that talks to the database. It's a popular model that emerged through things like PHP and dynamic pages. Programmers asked themselves, what are we doing? Oh this is it - Presentation / Logic / Database. That was then adopted as a "software architecture".

But why do you need custom code in between a web browser (presentation), and the database? It worked in the past before the web. Security was the original reason. But that was really a workaround. The real reason, is that databases don't "talk HTTP".

There's another way

These days GraphQL lets a browser (javascript) have a general-purpose way to talk to a database. That means there is no custom-human code in between that can introduce security bugs.

So the security risks that come with 3-tier software architecture is custom code. The risks have certainly been mitigated, but there's no need to continue that struggle. With GraphQL you practically eliminate the security issues, and also save time and money.

Logic on the side

So where does Logic fit in then? see https://colossal.gitbook.io/microprocess/comparisons/compared-to-multitier (I am an author of this draft document)

With Google Firebase, you use the client library to write directly to a collection, then have a Cloud Function activate upon that change on the collection.

It's possible to do the same thing with SQL as well - see https://colossal.gitbook.io/microprocess/definition/data-web-gateway. You modify records on a table, a NOTIFY/LISTEN mechanism (with PostgreSQL) activates a standalone background process that then responds.

It's also possible with GraphQL, but you have the added "layer" of the GraphQL language - which some need. You can accomplish the same underlying NOTIFY/LISTEN mechanism for logic.

With Logic responding to the database, you have no need for a separate event or queuing system, infrastructure is simplified, and you end up with a system that is less coupled than a microservices system.

Kind Contributor
  • 461
  • 2
  • 7
0

It depends on the kind of developers you have. I've seen it done well. I've seen it done badly because the middle-tier developers assumed that only their application would be calling it and didn't really have any security checks so if a user managed to call it directly they could do much more than they should be able to do.

Joshua
  • 1,090
  • 7
  • 11