Boycott Globals!

I'm stealing from Steffen Ullrich's comment, but the main issue with global variables is that they make it difficult to keep code well organized and maintainable. His link is a fine one, but you won't have any trouble finding countless articles about the problems with global variables online.

When you use global variables, it becomes easy to lose track of where in your program the variable gets modified, especially if you don't have a simple linear flow. As a result global variables can work perfectly fine in small scripts, but can cause massive headaches as an application begins to scale.

The main reason why I would avoid globals is because they make automated unit/integration testing a nightmare. Small applications can survive without tests, but trying to manage a larger application without good tests is just a nightmare (trust me, I tried in my young-and-foolish days).

This might leave you with the impression that globals are fine in very small applications, but since applications usually only grow over time, and things that start off temporary become permanent, it's really just a bad idea to use them at all. Why start on the wrong foot, when it is so easy to use properly scoped variables?

Security

Using global variables doesn't have any direct implications for security, but they do make it easier to end up with security issues:

If one loses track of where data comes from and modifies a function in file A but forgets that the utilized variable comes from user input in file B, it might end up doing insecure things on user input without proper safe guards.

Technically this is possible in any application, but global variables can certainly make it easier.

Global Variables == Death

I don't know of any breaches that happened specifically because of global variables, but it's easy to argue that the use of global variables has literally killed people, so I think it's reasonable to just never use them.

Examples

This is a good case where an example can help. For my example I'm going to harken back to the days of good ol' PHP in the early '00s. Many PHP frameworks from those days were filled with global variables and a complete lack of variable scope (aka this example is based on actual code I've seen over the years). Usually there is some settings.php file that creates lots of global variables:

settings.php:

$success_message = 'Your request was successful';

And then some sort of "controller" that does something and includes a php file that acts as the view:

register.php

if ($success) 
 include 'success.php';

success.php

<h2><?= $success_message ?></h2>

But then someone decides it would be better to include the user's name in the message when they submit the contact form.

The developer who receives this feature request comes up with a great way to make this happen for the contact form and other places that ask for a name. Therefore they do things "smart", go to the very bottom of settings.php and add this gem at the bottom:

(modified) settings.php

$success_message = 'Your request was successful';

// 100 other lines for various settings

$success_message .= " $GLOBALS['name']";

In case you didn't catch it, they just introduced a nearly system-wide XSS vulnerability. They took user input and dropped it into a global variable that previously contained perfectly safe data. This variable has now changed from innocuous to dangerous, with no warning. Someone looking at success.php will see it output a system-wide variable defined in settings.php. They will look in settings.php and see that it is defined as a constant, and is perfectly safe. They don't have any reason to scroll down and notice the fact that the whole system is completely owned.

That is the root of the issue. Doing something silly like the above and adding user input to a variable is an easy mistake to make. The issue with global variables is that it can completely separate related code, so when someone tries to track the flow of data through the application, they have to hunt through the whole source code to find potential changes. As a result it is very easy to introduce breaking vulnerabilities without realizing it, and it is is even easier for those issues to go unnoticed for extended periods of time.

In some programming environments, you can't trust the global scope since other sources could read / mess with it.

This has already led to some critical vulnerabilities in security sensitive products, like a remote code execution in the LastPass browser extension.

Please compare the following pieces of code:

1)

/file.php:
 $newconn = new PDO('mysql:host=localhost;charset=utf8mb4;','username','password');

2)

../secrets.php:
 $mysqlusername = 'username';
 $mysqlpassword = 'password';

/file.php:
 require_once('../secrets.php');
 $newconn = new PDO('mysql:host=localhost;charset=utf8mb4;',$mysqlusername,$mysqlpassword);

3

../secrets.php:
 function pdoconn(i) 
 $mysqlusername = ['username1','username2'];
 $mysqlpassword = ['password1','password2'];
 $conn = new PDO('mysql:host=localhost;charset=utf8mb4;',$mysqlusername[i],$mysqlpassword[i]);
 return $conn;
 

/file.php:
 require_once('../secrets.php');
 $newconn = pdoconn(0);

Example 1 is out of the question - incorrect configuration on production servers could end up showing sensitive parameters to unintended parties.

Example 2 is better, but those variables are available throughout the application, and modifiable, which could result in errors.

Example 3 keeps things very organised and transferable.

It can be modified to use globals if ../secrets.php instead was:

../secrets.php:
$mysqlusername = 'username';
$mysqlpassword = 'password';
function pdoconn() 
 $conn = new
PDO('mysql:host=localhost;charset=utf8mb4;',$GLOBALS['mysqlusername'],$GLOBALS['mysqlpassword']);
return $conn;

And I think that demonstrates why a global doesn't make sense most of the time in quite a succinct way.

Summary:

As for security breaches using global variables (and why I wrote these examples in PHP), there was quite a (at the time) controversial change in PHP 4.2.0 where register_globals was turned on to off. I can't find any articles now, as this change was made in 2002, but I do seem to remember it being responsible for a few breaches at the time. Copying directly from the manual, there is a very clear example of vulnerable code:

<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) 
 $authorized = true;


// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) 
 include "/highly/sensitive/data.php";

?>

They can give code injections easier access to everything

In PHP there is the $GLOBALS superglobal; in Python there is the globals() function, and in Javascript there is the window (or in Node, process) object. These all make it trivial to enumerate all global variables.

Once you do that you can both suck out the information they contain and change them maliciously. For example, if sensitive data is stored in a global, an attacker could easily extract it. If, say, a database connection URL is stored in a global, an attacker could point the URL to refer to the attacker's server instead, and then the victim would attempt to connect to that server and send credentials.

Also, if you have a lot of global objects then you can call their methods with ease.

They violate "principle of least privilege"

This principle of security engineering basically says "don't give someone more access than they need in order to do their job". Every function and method can read and write global variables even if they are totally irrelevant to its job, which means that if that piece of code is hijacked even in some limited way, it will open up a greater attack surface.

(Of course, most scripting languages have weak encapsulation rules which is also a violation of POLP, but if objects are out of scope then it is a lot harder to do anything to them.)

They are a breeding ground for buggy code

For reasons including:

• the programmer forgetting that one of the variables in a function is a global and thus changes made to it will persist when the function ends,


• the non-obvious sensitivity of the program to the order in which functions are called


• the ease with which cascade failures can happen (e.g. when a function sets a global to null and later another one crashes)


• the highly complex interactions which can easily occur and are hard to reason about

They are simply untidy

If you think about a business where there are papers strewn everywhere, things aren't organised and filed away neatly but just lying around, who's going to notice if something goes missing? If an employee commits fraud nobody will spot the discrepancy because discrepancies are everywhere. If a pair of keys goes missing, someone will just assume they're buried under something or someone had to borrow them.

Now you might say this is an exaggeration, but if so I doubt you've ever worked with a big software project. Globals are OK if your website is small enough to build in a couple of days (and you know what you're doing). They can save time to get something going.

But they don't scale.

Because the use of global variables gives you a bunch of problems, and not really any benefits.

Globals make your code hard to test

While not directly related to security, unit tests are vital to development. And in order to properly unit-test something, you need to be able to control the exact context in which code is executed. Look at the two pieces of code:

With Globals

public Money CalculateExpenses(int departmentId)

 Department department = (from d in global_db.Departments
 where d.Id = departmentId
 select d).Single();

 return (from ex in department.Expenses
 select ex).Sum();

Without Globals

public Money CalculateExpenses(int departmentId, Database database)

 Department department = (from d in database.Departments
 where d.Id = departmentId
 select d).Single();

 return (from ex in department.Expenses
 select ex).Sum();

You might say that the code looks almost identical, except for where the data is actually coming from. You might even think that the code with Globals is "cleaner", because you don't have to pass the database every time.

Until you have to write a unit test. Because then you will have to insert some logic to not connect to the production database, but rather some local, perhaps test-specific database. Now the non-Global code looks much better, because you can just pass the database you would like to use to the code.

In Summary: Code without Globals is easier to test.

Globals change behavior if you don't change the code

If your code has around 200 lines of code, then the usage of Globals doesn't seem so bad. In fact, it may seem like a perfectly valid thing to do if you re-use the same piece of code all over the place (e.g. some random data source, logging, etc.)

However, once your codebase grows enough, the introduction of globals can be absolutely deadly. You simply lose control over where your data is from, and who has access to it.

Let's use an example in everyone's favorite language: PHP 5. Example by Eevee.

 @fopen('http://example.com/not-existing-file', 'r');

What does this code do? You don't know, because it depends on global behavior. If PHP was compiled with --disable-url-fopen-wrapper, then it will not work. Same for the global configuration allow_url_fopen. We don't know what it will do.

The @ int the beginning will disable error messages, unless scream.enabled is set in the global PHP config. It will also not be printed if the global error_reporting level is not set. Where exactly it will be printed to, if it prints, will depends on the global display_errors.

So as you saw, the behavior of one innocuous line depends on 5 different global variables. Now imagine this scenario in a code base with one million lines, and 100 different programmers, all across different teams, and you will quickly see why the use of Globals is abhorrent and leads to all sorts of problems.

Imagine going to work one day and your code suddenly breaks, even though you haven't touched it. That's the magic of Globals.

There are more examples of why the use of Globals are bad, which can be found in the other answers.

Buffer Overflow Attacks

While fairly language-specific ( C/C++ come to mind ), and difficult to pull off, they are a potential attack.

Computerphile has a great video about it, that I wholeheartedly recommend, but here's a short version of the mechanics of this attacks and how it interacts with global variables.

A buffer overflow occurs when data written to a buffer also corrupts data values in memory addresses adjacent to the destination buffer due to insufficient bounds checking. This can occur when copying data from one buffer to another without first checking that the data fits within the destination buffer. (Wikipedia)

In the case of global variables, your program's memory layout is fairly static.

This is not specific to global variables, but holding meaningful information in such structures facilitates ( not to be mistaken with enabling! ) these kinds of attacks.

I have never had a problem with global variables in Bash or JavaScript, most likely because I only wrote small scripts for personal usage on minimalist environments.

Why do many programmers avoid using global variables and are there any examples of security breaches caused by using global variables?

In tiny projects global variables are just fine. Most of their problems don't show up.

And your entire customized bash environment state? Tiny.

Global variables start causing problems as your program scales. This happens in a bunch of ways.

But the core part of the problem is the amount of state that understanding each piece of code requires.

Imagine a 10 million line code base. In it, there are 1 million variables. All of them are global.

In a given 100 line piece of code, you might use 20 variables.

Whenever you call another function, you have no idea which of those 20 variables that other function will modify. When your function starts, you have no idea where the variable state came from.

So to understand what your 100 lines of code mean, you need to either understand and hold in your head all 10 million lines of code, or you need some kind of convention about where data is coming from, what data can and cannot be modified when you call a helper function, etc.

In contrast, if your code is almost entirely fueled by function arguments, local variables and return types, you only have to understand your function to understand what it does.

If it calls another function, you know what information you are passing to it, and what information it passes back. You might not know what it does with that information, but you know what it doesn't do. It cannot modify integer x and you are certain, because you didn't pass x to the function, nor did you assign to it from its return value!

Making code easier to reason about locally is a very important goal. You want to be able to read a function, know what it is doing, and identify bugs.

Writing code is far, far easier and far, far less important than making code that is clear and easy to reason about. Almost all code in a large, persitent project gets read 100s of times more often than it is modified, and it is written and designed once.

From this rule -- make stuff easier to reason about locally -- we reach the rule of "avoid global state".

Global variables that are read/written are an example of global state. But so can be some super-object that everything in your project has a pointer to passed as the first argument.

A super-object still has advantages over global variables; global variables often have confusing mechanics on how they are initialized and cleaned up (I'm looking at you, C/C++), and if you have a super-object with all of your "global" state you can instantiate two versions of your super-object and run both at the same time in the same process (this will tend not to work, but that is usually because of some implicit global state the OS foists on you).

Every global variable you read, instead of a parameter, means that any bit of code, anywhere could be modifying your behavior. Every global variable you write to means you are changing the behavior of some code arbitrarily far away.

And it isn't just humans who find global state a pain. If your state is local, writing test harnesses that "fake" a global state or environment becomes far easier. If there is (say) a global "mouse" object, writing a unit test that creates a fake mouse that pretends to do certain movement becomes harder. It may even be harder to write a macro that plays back a recorded mouse movement into some code, especially if you intend to do it while the UI remains responsive to the actual human using a mouse.

Security is a function of understanding what your code does. Security, within a program, means "your code only does what it is intended to be allowed to do"; with global variables, you have a weaker ability to understand what the code does, thus less ability to control what it does.

Why do many programmers avoid using global variables and are there any examples of security breaches caused by using global variables?

Because it's easier to modify code that doesn't use global variables to run in unintended applications, applications which the original developer didn't foresee. Really, if you depend on global state, you can have at most one such state in an application without intensive refactoring (which would refactor away the global state).

Such unintended applications might include making the code run in multi-threaded environments.

However, what many people fail to realize: malloc() is global!

The same people who advocate against using global variables are all the time using a global allocator state.

This means that if piece of your code allocates lots of memory, making malloc() request more memory from the operating system, the memory blocks get mixed up with those allocated from other pieces of your code, and when the same piece of code frees all of its memory it was using, the free() calls don't return memory back to the operating system due to fragmentation. The end result is that your program ends up using more memory than it should.

So, the very people who advocate against using global variables, are in fact using an allocator with a global state.

I wonder why none of the standards by the major standardization organizations (C89/C99/C11/C18 by ISO, POSIX by IEEE) have defined an allocator that allows you to have multiple allocator states, i.e. independent heaps.

If just about every programming language can declare a variable globally, accessible only within the scope of it's implementation code, then this is a non-issue. There isn't much reason to use global variables.

Yet, this isn't the case, which is why when I've found myself writing my projects in C & not in C++, where it is naturally supported as a static variable at the outermost clause of a class definition, I've had to make do with global variables.