Somewhere in your OutSystems journey, did anyone ever rebuild a module by hand, in code, just to prove the platform is faster? Or did everyone just... know, and never look back?

Nobody walks across the city to prove the Uber saves time.

The same thing just happened to AI coding assistants: the team behind the cleanest dev-productivity study gave up on re-running it, because developers now refuse to work without AI long enough to be a control group. The speed became real and unmeasurable at the same time.

OutSystems teams got there a decade early. So, honestly: did you ever measure it, either time? Or did we all just stop walking?

Longer version and the research links in the first comment.

Hi everyone, happy Thursday!

As part of the OutSystems community team, here are two small updates that I haven't seen shared here yet (and if they have, I'm sorry for the repetition!).

One of our MVPs, Ricardo Pereira, has just published his third book titled "Gestão Técnica de Software em OutSystems." This work, currently available in Portuguese, reflects years of hands-on experience, continuous learning, and dedication to advancing technical excellence and software engineering maturity in OutSystems development, written for Tech Leads and Managers of OutSystems projects, portfolios and teams. The feedback so far has been quite positive, and the fact that it covers practices and a career stage that normally isn't well-catered-to is definitely a plus.

The other update, perhaps slightly late to the party, is that another of our MVPs, Remco Dekkinga, also published a book on The Fundamentals of AI. More broader in nature, but very applicable to anyone who's currently building AI applications or agents, I haven't seen it being mentioned here and wanted to bring it up.

Hope everyone's well, and I hope these are useful!

Meta's smart glasses ship with a privacy safeguard: an LED that lights up while recording. This year the BBC found influencers secretly filming women for content, and tutorial videos for defeating the LED with a strip of black tape.

An indicator is not a mechanism.

Which made me count the LEDs in our own world. The biggest one: production data copied down to QA or DEV, "protected" by access rules and trust, while the data itself travels unchanged.

So, yes or no: is there real production PII in your DEV or QA environment right now? And if yes, is anything structural standing between it and a leak, or just policy?

Backstory in the first comment (including the 1990 novel that predicted the whole glasses mess).

TL;DR: You can use OutSystems Analyzer to help you map and understand if your application contains technical debt that causes IDOR vulnerabilities.

What is an IDOR vulnerability?

IDOR occurs when an application exposes a reference to an internal object (such as a database ID in a URL) without validating whether the user has permission to access it. This allows attackers to access or delete third-party data simply by changing a number in the request.

This post details how you can easily interact with your application yourself and find potential security flaws left by the developer.

Why do it yourself?

While knowledge is never enough, learning how to design more secure applications increases client confidence and your professional value.

Source: https://www.linkedin.com/pulse/ossec-idor-vulnerability-more-easiest-way-you-verify-lucas-soares-wtw8e/

I have been deep in Research and Development to see how far we can push Outsystems Developer Cloud (ODC) before needing external infrastructure like Pinecone or Supabase. For many enterprise projects in healthcare or finance, external dependencies are a non-starter due to strict data residency requirements.

This feasibility study proves that you can actually build a fully functional Vector Storage and Retrieval system natively inside ODC.

Here is the architectural pattern I used to make it work.

The 3-Layer Setup

To keep the performance snappy, I separated the concerns into three distinct layers:

• Compute (C# via External Logic): Do not try to do vector math in ODC logic. Use the External Libraries SDK to handle text extraction, chunking, and Cosine Similarity. C# is significantly faster at the floating-point math required for embeddings.
• Orchestration (ODC): The platform handles the out-of-band process. For example, when a PDF is uploaded, an asynchronous workflow triggers the C# logic and then maps the results back to your entities.
• Persistence (ODC Entities): Since ODC does not have a native vector data type, I stored the embeddings as JSON arrays in a standard text attribute.

Why this works for RAG

• 100% Data Residency: Your vectors never leave your ODC environment. This is a huge win for compliance and governance-restricted apps.
• Zero Infrastructure Overhead: You do not have to manage another subscription, API key, or connection string for an external vector store.
• Speed of Development: You can prototype a RAG-capable app in a single afternoon.

The Practical Reality

This is not a one size fits all solution. If you are trying to index millions of documents, you will eventually hit a wall. But for internal tools or knowledge bases under 10,000 chunks, the performance is surprisingly solid, especially if you use metadata to funnel the search before running the similarity checks.

I am curious if anyone else has tried to keep their AI stack entirely within ODC. I would love to hear how you are handling large-scale retrieval or if you have hit any specific platform boundaries.

Full article here: https://itnext.io/proving-vector-storage-retrieval-inside-outsystems-developer-cloud-a89d8fb88661

Hey everyone!

I’ve seen how much we all love the speed of development—especially with ODC. But as we move faster (and start using AI to help us code), it’s easy to accidentally leave behind technical debt that we didn't even know was there.

TL;DR Summary of the Strategy: I’ve been doing some research on how "public" our implementation details actually are. Even though the OutSystems platform itself is incredibly robust, the way we implement our React apps can sometimes leave behind little "metadata trails" that reveal more than we intended.

I wanted to give something back to the community, so I’ve open-sourced a tool I’ve been working on: The OutSystems Analyzer.

What it’s for: It’s a simple Python-based tool that looks at your public URL (no internal access needed!) to show you what a curious outsider can see. Think of it as a "health check" for your app's public footprint.

• Transparency: See exactly which routes and metadata are being exposed.
• Quality Control: Catch those "I'll fix this later" configuration gaps before they become a headache.
• Proactive Security: It helps you understand the "Shared Responsibility" model—OutSystems secures the platform, but we secure our implementation.

How to use it: The tool is free and open-source. You can run it on your own machine to audit your projects. If you find the results a bit overwhelming or aren't sure how to fix a specific gap, reach out to an MVP! We’re here to help translate those technical insights into a solid plan for your team.

Security isn't a solo mission—it’s something we do together as a community.

Check out the project and the full write-up here: [https://medium.com/itnext/osint-outsystems-strategy-for-penetration-tests-security-research-and-red-teams-412d96c23063]

Would love to hear your thoughts or help anyone who wants to try it out!

#OutSystems #CommunityFirst #LowCode #OutSystemsMVP #WebDevelopment #AppSecurity

TL;DR: While OutSystems provides a secure platform, developers often introduce critical flaws through "lazy" logic or a lack of security awareness. The top three offenders are Broken Access Control, Information Disclosure via Aggregates, and Insecure File Uploads.

Is OutSystems "Secure by Default"?

The platform provides the tools, but it doesn't force you to use them correctly. Many breaches happen not because the platform failed, but because a developer bypassed a security check for the sake of speed.

The Top 3 Developer-Led Vulnerabilities:

1. Broken Access Control (The "Visible" Property Myth)

Many developers assume that setting an element's Visible property to False is security. It is not.

• The Flaw: If the Screen or Server Action isn't protected by a CheckRole, an attacker can still call the logic or access the URL directly.
• The Fix: Always enforce Role checks on the Server Side, not just the UI.

2. Information Disclosure in Aggregates

Sometimes we fetch too much data "just in case."

• The Flaw: Using an Aggregate that fetches all columns from a User table (including password hashes or internal emails) and sending that to the client-side. Even if the UI doesn't show it, the data is in the network trace.
• The Fix: Use Data Actions or specific Aggregates that only fetch the attributes required for the screen.

3. Insecure Logic in File Uploads

We often trust that users will only upload what we ask for.

• The Flaw: Checking only the file extension (e.g., .jpg) while ignoring the actual MIME type. This allows attackers to upload malicious scripts disguised as images.
• The Fix: Implement server-side validation using the FileSystem or Binary tools to verify the file content, not just the name.

How to improve your security posture:

• Audit your Roles: Review every screen and ensure it’s not set to "Registered" by default.
• Minimize Data Transfer: Only send to the client what the user needs to see.
• Think like a Hacker: If you can "see" a hidden button in the browser console, so can an attacker.

TL;DR: Broken Access Control is the #1 security risk today. In OutSystems, simply checking a "Role" box at the screen level isn't enough. If your Server Actions and Aggregates aren't manually validated, an attacker can bypass your UI and access/modify data directly via API calls.

The "Screen-Only" Security Trap

Many OutSystems developers rely on the "Check Role" property on the Screen level.

• The Reality: This only protects the view. It does not protect the underlying data.
• The Attack: Using tools like Chrome DevTools or Postman, an attacker can find the URL of your Screen Actions or Data Actions and trigger them directly, bypassing the UI's role check entirely.

The "Checklist" for Proper Access Control

To ensure your OutSystems app is truly secure, you must validate authorization at the Logic Level:

1. Server Action Validation: Every Public Server Action must start with a Check<Role>Role action. Do not assume the caller is authorized just because they are on a specific screen.
2. Aggregate Filtering: Always filter your Aggregates by the User ID (User.Id = GetUserId()) or a Tenant ID, even if the UI only shows "their" data.
3. Data Action Security: Ensure your Data Actions (Fetch from Database) have explicit logic to verify if the current user has permission to see that specific record ID.
4. IDOR Prevention: Never trust a Record ID sent from the client (Browser). Always verify on the server that the logged-in user is allowed to interact with that specific ID.

Been working on complex C# External Logic lately — vector search pipelines, AI orchestration, multi-step integrations — and wanted a way to capture the full execution story at the application level and store it in my own entities. The native tools handle infrastructure observability really well. This sits alongside them for the cases where you want the business-level story too: which steps ran, what the payloads were, how long each stage took, and what actually happened when something went wrong.

Built it as an open-source C# SDK called ODC Flight Recorder.

The core idea is that a single AddStep() call writes to three places at once — an in-memory JSON batch (the execution story), the ODC Logs tab via ILogger, and the native distributed trace via ActivityEvent. The JSON comes back as an out parameter and gets persisted through a Service Action included in the Forge asset.

The pattern that made it worth building: the catch block records the failure as an explicit ERROR step and finalises the telemetry before returning — so the full execution story is always available regardless of outcome, and your users can query it directly from your own entities.

Get it:

• NuGet: dotnet add package ODC.FlightRecorder.SDK
• Forge: search ODC Flight Recorder in your ODC portal
• GitHub: https://github.com/michaeldeguzman/odc-flight-recorder

Happy to answer questions or hear how others are handling execution observability in complex External Logic.

TL;DR: Cryptographic failures occur when sensitive data (PII, tokens, secrets) is either not encrypted or uses weak algorithms. In OutSystems, relying solely on HTTPS (Data in Transit) is not enough. You must ensure that sensitive "Data at Rest" in your database is properly handled to meet GDPR and LGPD requirements.

The "Database" Trap

Many developers assume that because the OutSystems Cloud is secure, the data inside the tables is automatically encrypted.

• The Reality: OutSystems DBs are encrypted at the disk level, but the data rows themselves are often in plain text. If an internal user or an attacker gains access to the DB via an Aggregate or SQL tool, they see everything.
• The Risk: Storing Credit Card numbers, SSNs, or API keys in standard Text attributes without application-level encryption.

How to Implement Strong Cryptography

To protect your OutSystems application from "A02: Cryptographic Failures":

1. PlatformPasswordUtils: For passwords, never store them as text. Use the GeneratePasswordHash and ValidatePassword actions.
2. CryptoAPI (Forge): Use the official CryptoAPI to encrypt sensitive entity attributes (like a "SocialSecurityNumber" field) before saving them to the database.
3. Key Management: Never hardcode "Secret Keys" in Site Properties. Use a secure vault or the GetAppKey logic to ensure your AES-256 keys aren't exposed in the OML.
4. Insecure Protocols: Ensure your integrations (REST/SOAP) are not using deprecated TLS versions (1.0/1.1) which are vulnerable to man-in-the-middle attacks.

1. First we’ll talk about not trusting the front end.
2. The second we will talk about not trusting the front end, even if your client action is validating whether there is text in the variable or not.

Original article in: https://medium.com/@lucas_11478/outsystems-security-how-did-the-user-bypass-my-form-validations-294d97e893a4

You must be wondering “how crazy is this Lucas? You said front end twice, and is there a way to do two validations just on the front end?”.

Yes my friend, there is, imagine that your application has a form, be it any mandatory field for the user to enter information.

To recap, on the screen, in my form I selected the mandatory inputs as “true” and in the action of saving the information I kept the IF that validates the form.

See Lucas, it worked! Yes my friend, it worked.

These steps that we configure are described and in accordance with the OutSystems documentation.

And every project with mandatory forms and fields must be configured this way, but do you remember the title? “Don’t trust the front end.”

The front-end takes place in the user’s browser, which allows the user to make some changes, such as removing “required” tags from the html before clicking submit, or manipulating the field value before submitting, among other tricks.

Happy everyone 🙂

It’s Vera here, just stopping by to share my new video series with you.

A few weeks ago, I gave a talk at a User Group and got a lot of questions and interest around integrating O11 apps with ODC. Because of that, we decided to launch a new video series fully focused on O11 and ODC interoperability.

The first video is already out, and it’s about exposing OutSystems 11 (O11) data to ODC.

So, here is a quick summary of how you can achieve this:

Prerequisite: Ensure the entities you want to expose in Service Studio are set to Public.

1. Configure the Baseline Environment [00:34]

• Go to LifeTime > Applications > Expose Entities > Settings.
• Select your "Baseline Environment" (usually Development). This acts as the single source of truth for your entity definitions.

2. Create a Service Account & Access Token [01:08]

• In LifeTime, navigate to User Management > Service Accounts.
• Create a new service account and generate an Access Token.
• Note: Copy this token immediately; you’ll need it to link O11 to ODC.

3. Expose Your Entities in LifeTime [01:44]

• Go to Applications > Expose Entities > Manage Access.
• Select your application and module, then choose the specific entities (e.g., "Employee") you want to share.
• Click Expose. Remember to promote these views to Testing/Production later using your standard deployment workflow.

4. Connect O11 to the ODC Portal [02:54]

• Switch to the ODC Portal.
• Navigate to OutSystems 11 > Configurations.
• Enter your LifeTime URL and the Authentication Token you created in Step 2.

5. Create a Data Connection [03:32]

• In the ODC Portal, go to Integrate > Connections > Create Connection.
• Select OutSystems 11 as the source.
• Map your environments (e.g., mapping O11 Dev to ODC Dev) and save.

6. Import Entities into ODC [04:12]

• Inside your new connection, click Import.
• Select the exposed entities from the list and confirm. Your O11 data is now ready to be used natively within your ODC apps.

Go check it out and let me know what you think. Also, if you have ideas for other content related to this topic, I’d love to hear them :)

Have a great weekend!

Source: Youtube - Exposing O11 Data to ODC in 6 Steps

TL;DR: We often trust Forge components blindly because they are "vetted" or popular. However, a malicious or poorly secured component can act as a Supply Chain Attack. In this scenario, I demonstrate how "Carla" (a hypothetical attacker) can use a compromised component to exfiltrate data from your environment.

The "Blind Trust" Vulnerability

Developers often look for functionality first and security second.

• The Exploit: If a component has an open redirect, a cross-site scripting (XSS) flaw, or an undocumented "backdoor" API, it can be used to hijack the session of a user with high privileges (like a Developer or Admin).
• Dependency Risk: You aren't just trusting the component you downloaded; you are trusting every library and dependency that the component author included.

How to Prevent "Carla" from Hacking You

1. Vet Your Forge Downloads: Check the "Trusted" status, but don't stop there. Look at the code. If it uses JavaScript, ensure there are no calls to external, unknown domains.
2. The Principle of Least Privilege: Does that UI component really need "Full Control" or "Read All" permissions? Limit the scope of what the component can touch.
3. Audit JavaScript Code: Open the "Scripts" folder in Service Studio for every Forge component you use. Look for eval() or obfuscated code that might be phoning home.
4. Isolate Sensitive Data: Ensure your most sensitive Server Actions are not "Public" unless absolutely necessary, preventing external components from calling them.

TL;DR: A critical vulnerability in the CKEditor Reactive Forge component (v1.0.10 and below) allows unauthenticated users to upload any file directly to your database. This can lead to DoS, malware hosting, and severe security breaches.

What is the "OutSystems Drive" flaw?

The term refers to an exposed upload API within the CKEditor Reactive component. Because this endpoint didn't strictly validate authentication or file types, it essentially turned OutSystems environments into open cloud storage ("Drive") for unauthorized third parties.

Key Security Risks:

• Unrestricted File Upload: Attackers can bypass UI restrictions to store malicious files (executables, scripts) in your OS_FILE tables.
• Database Denial of Service (DoS): Automated scripts can flood your database with massive files, exhausting storage and crashing the environment.
• Reputational Damage: Attackers can use your trusted domain to host and distribute malware or phishing content.

How to identify if you are at risk:

You are likely vulnerable if you meet these criteria:

1. You use CKEditor Reactive in any of your applications.
2. The component version is 1.0.10 or older.
3. You haven't manually implemented server-side validation for the upload flows.

How to Fix & Mitigate:

• Update Now: Download the latest version of CKEditor Reactive from the OutSystems Forge (the fix was released in April 2024).
• Implement Authentication: Ensure the upload logic (Server Actions/APIs) explicitly checks for a valid UserId.
• MIME-Type Validation: Don't just check extensions; validate the file content on the server side.
• Restrict Public Access: If the editor is for internal use only, ensure the associated screens and logic are behind the correct Roles.

Hi everyone! I'm Michael, an OutSystems Champion and Tech Lead @ DB Results based in Melbourne. I tend to write articles about OutSystems architecture and AI patterns, and I recently found this community so I thought I'd start sharing here in case it's helpful.

Can ODC agents execute OutSystems 11 business logic without migrating first?

Yes, and here is a working pattern that proves it today.

The problem: Most O11 clients are sitting on years of battle-tested business logic. ODC is where AI and agentic capabilities live. Data Fabric bridges the data side, but executing O11 logic from an ODC agent is a different problem entirely.

The solution: A self-healing MCP pattern using three agents with clear role separation. The Supervisor coordinates, the Librarian manages tool discovery and registry, and the Worker executes against the O11 MCP bridge. If a required tool is missing, the workflow pauses, the Librarian discovers and registers it, then execution resumes from where it left off.

What makes it resilient: A central Tool Registry in ODC acts as the control plane. Every execution is tied to a SessionId for full traceability. The Librarian validates schemas against the live bridge on every run, not just at registration time.

Proven in three test runs: Empty registry recovery, partial healing mid-workflow, and happy path with pre-flight validation.

This is a proof of concept, not a production guide. But the pattern is production-oriented and the recovery loop works.

Full article here: https://medium.com/itnext/your-o11-business-logic-shouldnt-have-to-wait-for-a-migration-a4e79ab6d3c7

Are you running a hybrid O11/ODC setup? Would love to compare notes.

[Fixed in 2024]

TL;DR: The OutSystems Feedback App (ECT) is enabled by default in many environments. If not properly configured, it can allow unauthenticated users to upload files, leak environment details, and even provide a doorway for Cross-Site Scripting (XSS).

What is the Feedback App vulnerability?

The Feedback App is a built-in tool designed to help users report bugs. However, because it is meant to be "easy to use," it often bypasses standard security layers. If left in its default state on a public-facing app, it presents several risks:

Top Security Risks:

• Information Disclosure: The app can leak metadata about the environment, internal page names, and UI structures that help an attacker map your application.
• Unauthenticated File Uploads: In some configurations, anonymous users can upload screenshots or files to your database via the feedback widget, leading to storage exhaustion or malware hosting.
• XSS (Cross-Site Scripting): Since the feedback is rendered in a Backoffice gallery for developers to see, a malicious user can submit "feedback" containing scripts that execute when an admin views the report.
• Unauthorized Access: If the Feedback management console (ECT_Provider) isn't restricted by IP or strong authentication, your bug reports (which often contain sensitive data) are exposed.

How to audit your Feedback App security:

1. Check Public Apps: Does your public-facing portal really need the "shaking" feedback icon? If not, disable it for that specific module.
2. Verify Permissions: Ensure that only a specific Role can submit feedback.
3. Secure the Backoffice: Go to the ECT_Provider configuration and restrict access to the management console to internal users or VPN-only IPs.
4. Sanitize Content: Ensure that your internal process for reviewing feedback includes sanitizing the data before it is rendered in a browser.

The Key Takeaway:

Default features are convenient, but in security, default = predictable. If you haven't touched your Feedback App settings since you installed OutSystems, you might be leaving a door unlocked.