The Office 365 (and now Microsoft) Secure Score tool has proved popular with admins of organizations of various sizes that want to evaluate and improve the security and compliance posture of their cloud environment. While by itself the tool doesn’t necessarily offer any functionality you wouldn’t have access to in other parts of the service, putting all this information, recommendation and controls in a single page can definitely save some time. It’s certainly better than having to perform checks in a dozen different portals and PowerShell sessions, or go over lengthy Excel files such as the Customer Security Considerations Reference Guide available in the Security & Compliance Center.
Now, ironically, the Secure Score has suffered a minor issue, which causes some of the links in the tool to point to other tenant’s portals. For example, the screenshot below shows me logged in with a Demo tenant, looking at one of the SharePoint related controls in the Secure Score. Clicking the View Settings button in this case should take me to the SPO Admin center for the tenant, which should have the URL of https://m365x935757-admin.sharepoint.com/
Only in this case, it points to different organization’s SPO Admin Center URL, as illustrated above. And of course, trying to access this link will throw an error message, saying that the user I’m currently logged in cannot be found in the tenant’s directory. Luckily, no unauthorized access is being granted and no data is exposed.
The culprit here is the fact that the SPO URLs include the tenant name, and somewhere along the line it seems that the wrong variable is being passed. Most of the other links will be fine, as they are using the same URL across all tenants. For example, none of the links that take you to the Office 365 Admin Center, the Security and Compliance Center or the Azure portal will show the issue. Others, such as links to the Exchange Admin Center might have the other tenant’s name added, but will still take you to the correct place, as the corresponding portal properly recognizes your ID.
While overall this can be considered as a cosmetic issue, it’s yet another example of neglect of the proper coding and testing practices used by some teams at Microsoft. Of course code issues will always happen, but when something as obvious as the above makes it into production, it leaves you wondering do they even bother to check the actual end result, before dumping it on paying customers. And it’s even more concerning when such issues are affecting tools that aim to help you protect your organization.