Net API Notes for 2020/02/14 - Issue 121

Happy Valentines Day! What started out as a newsletter light on linked romance turned into a love letter to API security. C'est la vie.

To the notes!

NOTES

SHOULD I USE MICROSERVICES?

In my look-ahead 2018 newsletter, I described how we were fast approaching "peak microservices". I could see the growing push-back on the architectural style leading to the rash of anti-microservice pieces last year. It was microservices own "trough of disallusionment".

It is against this backdrop that Sam Newman has posted a piece entitled "Should I use Microservices?". Sam is author of the some-wholesome-I'd-share-it-with-my-Mother "Building Microservices", as well as "Monolith to Microservices". He knows a thing or two (thousand) about the space.

Like most initial proponents, he wholeheartedly rejects the idea of making microservice architectures the default approach to software. His piece discusses where microservices aren't great. He also lists a significant number of places where it does make sense.

If the recent rash of conflicting microservice advice has left you confused about its value, this Sam Newman piece is a reset on the fundamentals.

API SECURITY

Mike Kelly, author of the HAL specification, has built a career working in banking and financial environments. As such, he knows a thing or two (thousand) about securing sensitive APIs. He recently asked whether anyone would be interested in a guide on designing secure APIs.

This is a big topic. Off the top of my head, API security issues include:

• Secure channels - Everything should be TLS 1.2 (or later) versions; this should be obvious, but unstated assumption is how the Cats Movie got made.
• Validate Inputs - Values submitted should be treated as untrusted and validated before subsequent processing; enumerated valid values, schemas, and enforced data formats, like ISO8601, are your friends here.
• Avoid Sensitive Data in URLs - If I have a collection of people at a given endpoint, like ~\people, it may be tempting to filter the results of a GET by passing a unique identifier, like TaxId, as a query param: ~\people?taxid=287984690 (this is a faked number, btw). The problem is that sensitive PII is now stored in any number of log files between the caller and the provider. Adjust the design accordingly.
• Tokenize Sensitive Values - What's better than banishing sensitive information to the body of the request (where it is less likely to be logged)? Not sending the sensitive information at all. Instead, fields are translated to an arbitrary value, or token, meaningless by themselves. Then that value is transmitted.
• Datensparsamkeit - What's better than tokenizing sensitive information? Not having to send it at all. Too often, I see designers take a kitchen-sink approach to the data made available via an API. It's an attitude of "I'm not sure what will be valuable, so I'll just expose it all". Don't do that. Store and expose only what is needed. The German's have a word for it: Datensparsamkeit.
• Use Industry Hardened Authentication and Authorization - OpenId and OAuth 2.0 are well documented, used by numerous vendors, and scale. Don't reinvent the wheel.
• Rotate Keys - You know what a bigger pain is than setting up regular, automatic key rotation? Dealing with a breech.
• Leverage Gateways and Proxies - Expecting individual teams to consistently implement security practices, like key rotation or OAuth handling, can be tricky. This is where having a centralized proxy or gateway perform that service for all API traffic becomes useful.
• Scan Logs - It can be easy to treat logs as exhaust from normal business operations. However, there can be a wealth of sensitive information accumulating in locations less secured than "official" access channels. Like code should be scanned for deficiencies prior to run-time, logs should be scanned for problems after.

There's much more to this. APISecurity.io, for example, covers API security issues on an ongoing basis. If you've got additional relevant areas for Mike, reach out on Twitter and let him know.

MILESTONES

• Facebook released a collection of data for use by researchers(no, it's not the exabyte the Facebook claimed in a press release - it's 100,000 times smaller, or 10TB). You may recall, last year, that more stringent access caused havoc on researchers attempting to hold social media platforms accountable. Early sentiment? There's a complex application process to get access, there's no ability to download, and some researchers are already saying what's there isn't worth the trouble.
• Canada is publishing API guidelines.. A minor bug-a-boo I have is they codify the "API-as-CRUD" mentality. They could also benefit from a "MUST", "MAY", "SHOULD" approach as outlined in RFC 2119 (something my team has recently undertaken to clarify our standards). However, grousing about those couple of details is like having to squint on an otherwise sunny day; I'm glad this exists, and more public institutions should emulate it.

WRAPPING UP

I try and ensure that I keep this newsletter highly focused; you're busy, I'm busy, and there's only so much distraction necessary to while away time in the restroom (for now). Occasionally, however, I must make an exception.

I've been experiencing the Baader-Meinhof phenomenon hard since putting together last year's Agile Antipatterns. I see folks are challenging conventional software development wisdom from a variety of different angles. And then Dorian Taylor goes and writes a piece entitled Agile as Trauma. Masterful.

I've updated NetAPI.events to include the newly christened API Community Belgium. Welcome! If you know of an upcoming, in-person meetup or event that should be listed like the one in Brussels, let me know.

Finally, thank you to my Patreons. They'll be getting these fancy-schmancy (and legally-dubious) laptop stickers. Sign up to be a Patreon today to get a set of your own!

Till next time,

Matthew @libel_vox and matthewreinbold.com