A string (or string, String, str, char*… you name it) is a sequence of bytes or characters. In most high-level programming languages, including Java and C#, a string consists of an immutable array of characters.

They tend to look something like this.

That's the length of the string, which itself takes up a fixed number of bytes (four in Java), and then a series of characters, which each take one or more bytes. Java uses UTF-16, in which most characters are two bytes, but some are three.

You can put quite literally anything into a string (assuming infinite memory). They can accept any valid character, and as many of them as you want. The entire works of Shakespeare will happily sit in a string in a program on your computer, and take up a grand total of six whole megabytes of memory.

We often use strings to store arbitrary, human-written text, but it's even more common to store computer-generated streams of characters. There's a hell of a lot of XML and JSON out there in the world, and humans are simply not capable of typing it all. Most of the time, the majority of a string is infrastructure to help a computer, not a human, read the important bits.

It turns out strings themselves are very useful. Having the ability to move around arbitrary amounts of data encoded in a fashion anything can understand has served software developers very well. Unfortunately, there's a few things you can do with strings which undermine everything.

The first:

Yup, concatenation. That beast. Now the second:

Oh, splitting. You devil, you.

Hold your arguments for now. All will become clear.

There's a piece of code everyone has written at least once. You've done it. I've done it. Your old computer science lecturer does it all the time.

It looks like this:

There's some serious problems with this. And I don't mean that it's not using a StringBuilder. It's unreadable. It doesn't tell you what it's doing or why it's doing it.

This piece of code is really doing two things. First of all, it's converting everything into a string. Secondly, it's sticking them together with ", " interspersed.

Let's do that as two operations.

Not much better, is it? But now we can break it apart:

And then ship it out:

This is a clear example of how separating our concerns and focusing on one thing at a time can really improve our code quality. If we were worried about the performance of creating a second list, we could easily optimise the join method, and every caller would benefit for free.

Often, our data isn't quite as structured as we'd like. You know when this happens when you receive a CSV file with instructions to pull the relevant bits out. Finding those relevant bits can sometimes be harder than you think.

That's way nicer than the same behaviour in Java 7, but it's still got more than a few problems. First of all, it's common for text to have commas (,) in it, and it's common for CSV files to have a bit of free text. So what do we do when we have a comma? We put quotes around the entire text, of course.

Suddenly this got a lot more complicated.

UGH.

Now, we're still missing a lot.

• You need to be able to escape the quote character, because sometimes you'll need it inside a string.
• Quoted fields can span multiple lines.
• Every row should contain the same number of comma-separated fields.

But here's the real problem. There's tight coupling between reading the file and creating our Toolbox objects. We can remedy that by returning a stream and letting the caller construct the object:

The caller is now also responsible for closing the file, but hopefully we've made that clear in the method name. Now we can move our CsvReader to another package, or perhaps an entirely different module, and work on it separate from the business logic.

CSV-reading, among many other things, is infrastructure-level code. It should not be intermingled with application-level concerns. Decoupling these two will make the real purpose of the application much clearer.

Here's a thing we do way too often:

That's a lot of boilerplate to be copied around anywhere tools are used.

Instead, what about this?

Depending on the desired behaviour, Tool could be an interface, an enumeration, or just a simple class wrapping the name. But it offers us several advantages.

First off, we've moved the error-checking somewhere else, either to the thing that constructs the Tool or the Tool's own constructor. By converting the string into a domain object as soon as possible, we've moved our error-handling to a much earlier point in the application flow, allowing us to trust the objects in our system from that point onwards.

Secondly, we've made it absolutely obvious to any caller of this code exactly what we do and do not accept. They don't have to worry about casing, language or anything else: they know they need a Tool object, and provided they can find one of those, they're good.

Thirdly, it's far more extensible. If at some point in the future, the colour of a tool becomes something to consider when checking whether a tool is contained by a toolbox, we don't have to change the parameter list of this method, which means callers don't have to care. Only the implementation needs to change.

Pop quiz: what's wrong with this code?

If you said that it's not using String.format, you get a demerit. Stay after class.

I think most of you will know this one already. It's subject to an SQL injection attack. Sure, calling it with something like authenticate("steve", "open-sesame") is totally fine, but what about this?

The resulting SQL will look like this:

In most databases, -- marks the start of a comment, which continues until the end of the line, totally removing the password check from the equation.

Yup. Turns out that username will get you into a lot of badly-written websites. And it's easy to test for. On the really broken ones, using ' in your username or password will crash the website.

The correct way to do things is to, of course, use parameterised SQL:

This way, the database will handle the user-supplied input separately from the SQL itself, which means (assuming the database driver has been written well) any SQL in the user input will be treated as text, not code.

A number of threats to security involve convincing a program to treat data as executable instructions. Most of the attacks on Microsoft and Oracle which mean you have to update Windows and Java every seventeen minutes buffer overflow attacks. Because arrays aren't really a thing in C, you can overflow the array by simply writing past the end of it; there are no checks to ensure user input fits inside the array. If you are familiar with the memory layout of the application, you can write enough that you overwrite machine instructions with your own, giving you complete control of the application execution simply by providing more text than was expected.

Earlier, we pulled some data in from a CSV file. Now we're going to send out some HTML.

We won't make the same mistake we made with the SQL. No concatenation, this time. We're going to use a templating library. Our template will look something like this:

Easy. Sorted. Cushty.

Except no. What if one of the reviews looks something like this?

Lovely. Everyone will be redirected to an evil website, and no one will read the other marvellous reviews. Sad faces all around.

This is known as a cross-site scripting vulnerability, or "XSS", because it's often used to inject a script from another, malicious domain. It's a very common style of exploit on the web today.

We could escape the text by using the ?html post-processor (${review.text?html}):

Great. Now go do that for all your HTML. And don't forget any!

How about we write code that really does separate the instructions from the text instead?

This may look ridiculous, so allow me to explain.

For each element type, we have a method. Here, I've used static methods to keep it a little shorter, but they could just as well be instance methods.

Here's the signature of the section method:

Everything is a Node, not a string. Node's an interface that looks something like this:

There are three implementations of Node: Element, Attribute and Text. They all know how to render themselves, and Text class will escape any HTML special characters as it does so. This means that as long as we get the three implementations of toXml correct, which we can do with a pretty high confidence level just by writing a bunch of test cases, it should be impossible to inject HTML.

I should probably add that this HTML-building library doesn't actually exist. However, if you promise me you'll use it, I will build it for you. I think it's almost as easy to read as the HTML equivalent.

In June of 2014, this tweet became very famous:

Take a look at the number of retweets. This one is pretty special, but not for the reasons you might think. It exploited a bug in TweetDeck to perform an XSS attack. Fortunately, it was benign: it just popped up an alert box and retweeted itself to make everyone aware of the issue; not every attack is so friendly.

That heart at the end isn't for fun, though. This attack only works when the closing script tag is followed by a multi-byte UTF-8 character; simple ASCII doesn't trigger it, but when there's emoji, that code path gets hit.

The problem?

The relevant bit:

innerHTML is the problem here. Any time you end up setting the HTML of an element directly, just like in the template above, you have to escape it. Failure to do so often causes bugs of this seriousness (though not normally of this scale).

Sure, we can escape when necessary and hope we've covered all the bases, but there's a better way: just don't do it. Setting the textContent field instead, and constructing elements using the provided functions rather than concatenating HTML together, avoids problems like this.

Strings are the most powerful tool we have in our programming languages. Like all things powerful, they should be used responsibly.

Misuse of strings can lead to bad software design, such as coupling infrastructure to business logic, which can make your code hard to extend, maintain, support and test. I'd argue that strings are actually an infrastructure-level concern, and that any code related to your core logic shouldn't touch them at all.

Perhaps more importantly, strings stop us from guaranteeing correctness. Types are scary to some people, but strong wrappers for your data are important, because they stop us from creating massive security vulnerabilities. Munging HTML or SQL together by concatenating strings is convenient, but offers nothing in the way of security. Only by dealing with data as data and code as code can we avoid this.

There's a solution to both of these: use your type system properly. Create classes that wrap strings, and only expose the string itself (or a transformed variation) at the infrastructure level. Only split strings when you're ingesting the data, and at no point after. Until you need to output anything, don't concatenate at all—just store the data in sensibly-named fields and do all the work at once at the end. This helps us re-use code, avoids mixing the business with the underlying technologies and enables us to use our object-oriented programming language as it was designed, by adding methods to objects as more behaviour is required.

If you have a decent separation between your business logic and your infrastructure code, any code that munges strings belongs in the infrastructure layer, along with your HTTP endpoints, message queue adapters and database connections. You don't need them until you need to communicate with a third-party system, just like your adapters.

So, in summary, wrap your strings. Wrap them as early as possible, and don't expose them until the last possible moment.

Give it a try. I think you'll be pleasantly surprised.