All posts · General

Security Best Practices for Oracle Cloud PaaS Development

Building secure Oracle Cloud applications and integrations from the ground up — authentication, authorisation, data protection, and secure API design.

Anurag Jangra · January 29, 2026 · 6 min read · ... views

Security as a design concern, not an afterthought

The most expensive security fixes are the ones made after production deployment. Building security in from the start is both cheaper and more effective.

Authentication: use OAuth 2.0, not Basic Auth

Basic authentication (username/password in every request) is simple but risky:

  • Credentials transmitted with every call (even if HTTPS protects in transit)
  • Password rotation requires updating every integration
  • No expiry — compromised credentials work indefinitely

OAuth 2.0 Client Credentials with short-lived tokens (60 minutes) is the correct approach for OIC-to-Fusion API calls.

Service account hygiene

Every OIC integration that calls an API should have its own dedicated service account with the minimum necessary roles. Never:

  • Use a real user’s account for integrations (when they leave, everything breaks)
  • Use a single super-user account for all integrations (one compromise = all integrations exposed)
  • Store service account passwords in integration configuration as plain text

Use OCI Vault or OIC’s native credential store for secrets.

Data in transit and at rest

Always use HTTPS for REST API calls — never HTTP, even internally. OIC enforces this for cloud connections. For file transfers, use SFTP not FTP. For sensitive file content (financial data, personal data), apply PGP encryption before transfer.

For sensitive data stored in ATP databases, enable Oracle Database’s Transparent Data Encryption (TDE) — it encrypts at the storage layer with no application changes required.

Input validation and injection prevention

For dynamic SQL in PL/SQL: always use bind variables, never string concatenation with user input. For OIC XSLT transformations on inbound data: validate schema before processing, reject payloads that don’t conform.

PII and GDPR considerations

For applications handling personal data (employee records, customer data):

  • Log only what’s necessary — avoid logging full payloads containing PII
  • Implement data retention policies — purge old logs and staging data
  • Document data flows (what data goes where) — required for GDPR compliance

Security review checklist

Before go-live, verify:

  • No hardcoded credentials in integration code or templates
  • All API connections use OAuth or certificate-based auth
  • Role assignments follow least-privilege principle
  • Sensitive data fields are masked in error logs
  • Connectivity Agent server has OS-level security hardening applied

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp