OutSystems Security Specialist key terms

The process of verifying that a user or system is who it claims to be, typically by checking credentials such as a password, a federated identity assertion, or a certificate before granting access.

The decision about what an already-identified user is allowed to do. It maps an authenticated identity to permissions, roles, or screens and is enforced after authentication succeeds.

An external trusted service that authenticates users and issues assertions about their identity to relying applications. In OutSystems, federation to an IdP lets users sign in with corporate or social credentials.

An XML-based federation standard where an identity provider sends signed assertions to a service provider. OutSystems supports SAML for enterprise single sign-on with platforms such as Azure AD or Okta.

An identity layer built on OAuth 2.0 that returns an ID token describing the authenticated user. It is commonly used for social and modern enterprise login in OutSystems applications.

A delegation framework that issues access tokens so an application can call protected APIs on a user's behalf without handling the user's password. It handles authorization, not user authentication by itself.

A setup where one successful login grants access to multiple applications, so users authenticate once at a central provider. It reduces password sprawl but makes the central identity a high-value target.

Requiring two or more independent proof types, such as a password plus a one-time code or hardware key, before granting access. It limits damage when a password alone is stolen.

A short code valid for a single login attempt or brief window, often generated by an authenticator app or sent by message. It adds a possession factor on top of a password.

A server-side record of an authenticated user's login state, referenced by a cookie or token. Sessions must expire, be invalidated on logout, and resist hijacking through secure cookie settings.

An attack where an adversary plants a known session identifier on a victim, then reuses it after the victim logs in. Rotating the session ID at authentication defeats it.

Stealing or guessing a valid session identifier to impersonate a logged-in user. Secure cookies, HTTPS-only transport, short timeouts, and binding tokens to context reduce the risk.

Configuring browser cookies with attributes such as Secure, HttpOnly, and SameSite so session identifiers are not exposed to scripts, plaintext channels, or cross-site requests.

A compact signed token carrying claims about a subject, often used for API authorization and OIDC identity. Signature and claim validation, including expiry and audience, are mandatory before trusting it.

Checking a token's signature against trusted keys and verifying claims such as issuer, audience, and expiration. Skipping any check lets attackers forge identities or replay stale tokens.

Cryptographically signing SAML assertions or tokens so the receiving application can prove they came from the trusted identity provider and were not altered in transit.

Granting permissions through roles assigned to users rather than per-user rights. In OutSystems, roles gate screens, server actions, and exposed integrations, and are checked server-side.

An OutSystems setting that restricts which roles may open a screen. It is a UI convenience only, so server actions and data access must still enforce their own authorization checks.

Performing authorization and validation checks in server logic rather than relying on hidden UI elements. Attackers can call server actions directly, so client-side restrictions alone never protect data.

Giving users, roles, service accounts, and database connections only the permissions needed for their task, and nothing more, to shrink the blast radius of a compromise.

Gaining permissions beyond those granted, either by exploiting flaws to raise one's own rights or by abusing another account with broader access. Strict role checks and input validation counter it.

A flaw where an application exposes an internal identifier and lets a user access another user's record by changing it. Every data fetch must verify the caller owns or may see that record.

A broad weakness class where restrictions on what authenticated users may do are missing or bypassable, letting them read or change data outside their intended scope.

An OutSystems REST endpoint published for external callers. Each method needs authentication, authorization, input validation, and rate limiting, because it is reachable without the application UI.

A front layer that authenticates, throttles, and routes API traffic before it reaches backend services. It centralizes token checks and rate limits but does not replace per-action authorization logic.

The protocol that encrypts and authenticates traffic between clients and servers. OutSystems enforces HTTPS for applications and integrations so credentials and data are not sent in plaintext.

Redirecting or rejecting plain HTTP requests so all traffic uses TLS. It prevents downgrade attacks and stops credentials or session cookies from crossing the network unencrypted.

The HTTP Strict Transport Security header instructs browsers to use HTTPS only for a site for a set period. It blocks silent downgrade to HTTP and can include subdomains.

Hard-coding or tightly restricting which TLS certificate or public key an application trusts for a host. It stops man-in-the-middle attacks using rogue certificates but complicates certificate rotation.

A named combination of key exchange, encryption, and hashing algorithms used in a TLS connection. Weak or outdated suites should be disabled so only strong, current algorithms are negotiated.

An adversary secretly relays or alters traffic between two parties who believe they talk directly. TLS with proper certificate validation is the primary defense on untrusted networks.

A TLS mode where both client and server present certificates, so each side proves its identity. It is used to secure service-to-service integrations that do not involve a human login.

Information whose exposure causes harm, such as personal data, credentials, payment details, or health records. It needs classification, restricted storage, and protection in transit and at rest.

Labeling data by sensitivity level so handling rules, access limits, and retention apply consistently. Classification drives which fields may be stored, logged, or shown unmasked.

Storing data in encrypted form so stolen disks, backups, or database files are unreadable without keys. Key management and access to keys must be separated from the data store.

A one-way transformation producing a fixed-length digest used to verify integrity or store passwords. Password hashing needs a slow, salted algorithm such as bcrypt or Argon2, never plain SHA-256.

Random data added to each password before hashing so identical passwords produce different digests. It defeats precomputed rainbow tables and must be unique per stored credential.

Replacing part of a sensitive value with characters or tokens so users see only what they need, such as the last four digits of a card. It limits exposure in screens, logs, and exports.

The lifecycle of cryptographic keys: generation, storage, rotation, access control, and destruction. Poor key handling undermines encryption, so keys belong in a managed vault, not in source code.

Storing credentials, API keys, and connection strings outside code and configuration files, typically in a vault or secure setting, with access logged and rotation supported.

Passwords or keys written directly into source code or module settings, where they leak through repositories, exports, and logs. Secrets should be injected from a managed store instead.

Checking that data entering the application matches expected type, length, format, and range, on the server. It blocks injection and malformed payloads before they reach storage or logic.

An attack where untrusted input is interpreted as code or commands, as in SQL or command injection. Parameterized queries, allowlists, and server-side validation prevent it.

Injecting script into pages viewed by other users, which then runs in their browser context. Output encoding and a strict Content Security Policy are the main defenses.

Tricking a logged-in user's browser into sending an unwanted state-changing request to a site they trust. Anti-forgery tokens and SameSite cookies mitigate it.

A response header that tells the browser which script, style, and frame sources are allowed. A strict policy limits the impact of injected scripts and blocks unauthorized content.

A tamper-resistant log of security-relevant events such as logins, permission changes, and sensitive data access. It supports detection and investigation, and must never record secrets or full personal data.

Capping how many requests a client may make in a time window, which slows brute-force login attempts and abusive API calls. It complements, but does not replace, strong authentication.

Authorized simulated attacks against an application to find exploitable weaknesses before adversaries do. Findings should feed a remediation cycle, with retesting to confirm fixes.