3 Ways No-Code Developers Can Shoot Themselves in the Foot

There used to be a time where risk-averse organizations could severely limit their business users' ability to make costly mistakes. With limited technical know-how, strict permissions, and lack of tailwind, the worst thing a business user could do was download malware or fall for a phishing campaign. Those days are now gone.

Nowadays, every major software-as-a-service (SaaS) platform comes bundled with automation and application-building capabilities that are designed for and marketed directly to business users. SaaS platforms like Microsoft 365, Salesforce, and ServiceNow are embedding no-code/low-code platforms into their existing offerings, placing them directly in the hands of business users without asking for corporate approval. Capabilities that were once available only to the IT and development teams are now available throughout the organization.

Power Platform, Microsoft's low-code platform, is built into Office 365 and is a great example due to Microsoft's strong foothold in the enterprise and the rate in which it is adopted by business users. Perhaps without realizing it, enterprises are placing developer-level power in the hands of more people than ever before, with far less security or technical savvy. What could possibly go wrong?

Quite a lot, actually. Let's examine a few real-world examples from my experience. The information has been anonymized, and business-specific processes were omitted.

Situation 1: New Vendor? Just Do It

The customer care team at a multinational retail company wanted to enrich their customer data with consumer insights. In particular, they were hoping to find more information about new customers so that they could better serve them, even during their initial purchase. The customer care team decided on a vendor they would like to work with. The vendor required data to be sent to them for enrichment, which would then be pulled back by their services.

Normally, this is where IT comes into the picture. IT would need to build some sort of integration to get data to and from the vendor. The IT security team would obviously need to be involved, too, to ensure this vendor can be trusted with customer data and approve the purchase. Procurement and legal would have taken a key part, as well. In this case, however, things went in a different direction.

This particular customer care team were Microsoft Power Platform experts. Instead of waiting around for resources or approval, they just went ahead and built the integration themselves: collecting customer data from SQL servers in production, forwarding it all to an FTP server provided by the vendor, and fetching enriched data back from the FTP server to the production database. The entire process was automatically executed every time a new customer was added to the database. This was all done through drag-and-drop interfaces, hosted on Office 365, and using their personal accounts. The license was paid out-of-pocket, which kept procurement out of the loop.

Imagine the CISO's surprise when they found a bunch of business automations moving customer data to a hard-coded IP address on AWS. Being an Azure-only customer, this raised a giant red flag. Furthermore, the data was being sent and received with an insecure FTP connection, creating a security and compliance risk. When the security team found this through a dedicated security tool, data had been moving in and out of the organization for almost a year.

Situation 2: Ohh, Is It Wrong to Collect Credit Cards?

The HR team at a large IT vendor was preparing for a once-a-year "Give Away" campaign, where employees are encouraged to donate to their favorite charity, with the company pitching in by matching every dollar donated by employees. The previous year's campaign was a massive success, so expectations were through the roof. To power the campaign and alleviate manual processes, a creative HR employee used Microsoft's Power Platform to create an app that facilitated the entire process. To register, an employee would log in to the application with their corporate account, submit their donation amount, select a charity, and provide their credit card details for payment.

The campaign was a huge success, with record-breaking participation by employees and little manual work required from HR employees. For some reason, though, the security team was not happy with the way things turned out. While registering to the campaign, an employee from the security team realized that credit cards were being collected in an app that did not look like it should be doing so. Upon investigation, they found that those credit card details were indeed improperly handled. Credit card details were stored in the default Power Platform environment, which means they were available to the entire Azure AD tenant, including all employees, vendors, and contractors. Furthermore, they were stored as simple plaintext string fields.

Fortunately, the data-processing violation was discovered by the security team before malicious actors — or compliance auditors — spotted it. The database was cleaned up, and the application was patched to properly handle financial information according to regulation.

Situation 3: Why Can't I Just Use Gmail?

As a user, nobody likes enterprise data loss prevention controls. Even when necessary, they introduce annoying friction to the day-to-day operations. As a result, users have always tried to circumvent them. One perennial tug-of-war between creative business users and the security team is corporate email. Syncing corporate email to a personal email account or corporate calendar to a personal calendar: Security teams have a solution for that. Namely, they put email security and DLP solutions in place to block email forwarding and ensure data governance. This solves the problem, right?

Well, no. A repeated finding across large enterprises and small businesses finds that users are creating automations that bypass email controls to forward their corporate email and calendar to their personal accounts. Instead of forwarding emails, they copy and paste data from one service to another. By logging into each service with a separate identity and automating the copy-paste process with no-code, business users bypass security controls with ease — and with no easy way for security teams to find out.

The Power Platform community has even developed templates that any Office 365 user can pick up and use.

With Great Power Comes Great Responsibility

Business user empowerment is great. Business lines should not be waiting for IT or fighting for development resources. However, we can't just give business users developer-level power with no guidance or guardrails and expect that everything will be alright.

Security teams need to educate business users and make them aware of their new responsibilities as application developers, even if those applications were built using "no code." Security teams should also put guardrails and monitoring in place to ensure that when business users make a mistake, like we all do, it will not snowball into full-blown data leaks or compliance audit incidents.