This document provides security guidelines and best practices for deploying and developing with Apache Axis2/C.

Jira Reference: AXIS2C-1708 - Security hardening initiative tracking the methodology, planning, and progress of the security improvements documented here.

Axis2/C supports two XML parsers:

1. Guththila (default) - The recommended parser for production use
2. libxml2 - Alternative parser with additional features

Guththila is inherently secure against XXE (XML External Entity) attacks because it:

• Does not process external entities
• Does not load external DTDs
• Drops all unknown entity references

No additional configuration is needed for XXE protection with Guththila.

When building with --enable-libxml2, the following security measures are automatically applied:

Parse Options:

• XML_PARSE_NOENT: Substitutes entities (libxml2 2.9+ has built-in expansion limits)
• XML_PARSE_NONET: Forbids network access for external entities
• XML_PARSE_NOXINCNODE: Prevents XInclude processing

Runtime Limits:

• AXIS2_XML_MAX_DEPTH (256): Maximum element nesting depth
• AXIS2_XML_MAX_ATTRIBUTES (256): Maximum attributes per element
• AXIS2_XML_MAX_NAMESPACES (64): Maximum namespace declarations per element

Global Protections:

• Custom external entity loader that blocks ALL external entity resolution
• This provides defense-in-depth even if parse options are bypassed

These measures prevent:

• Local file disclosure via file:// URLs (XXE)
• Server-Side Request Forgery (SSRF) via http:// URLs
• Denial of Service via exponential entity expansion (billion laughs)
• Stack exhaustion via deeply nested XML
• Memory exhaustion via excessive attributes

XXE (XML External Entity) attacks can occur when XML input containing external entity references is processed unsafely. Axis2/C protects against these attacks in both supported parsers.

Attack vectors blocked:

<!-- Local file inclusion (blocked) -->
<!DOCTYPE root [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<root>&xxe;</root>

<!-- Remote file inclusion (blocked) -->
<!DOCTYPE root [<!ENTITY xxe SYSTEM "http://attacker.com/data">]>
<root>&xxe;</root>

<!-- Billion laughs DoS (mitigated) -->
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;">
  ...
]>

Axis2/C SSL transport is configured with modern security defaults:

1. TLS 1.2+ required - TLS 1.0 and TLS 1.1 are disabled (RFC 8996 deprecation)
2. SSLv2 and SSLv3 disabled - Prevents POODLE (CVE-2014-3566) and DROWN (CVE-2016-0800)
3. Compression disabled - Prevents CRIME attack (CVE-2012-4929)
4. Strong cipher suites - AEAD ciphers only (GCM, ChaCha20) with forward secrecy
5. Hostname validation - Certificate CN/SAN fields verified against target host

The following cipher suites are preferred (in order):

• ECDHE+AESGCM - ECDHE key exchange with AES-GCM
• DHE+AESGCM - DHE key exchange with AES-GCM
• ECDHE+CHACHA20 - ECDHE with ChaCha20-Poly1305
• DHE+CHACHA20 - DHE with ChaCha20-Poly1305

Excluded cipher suites: NULL, EXPORT, DES, 3DES, RC4, MD5, PSK, SRP, DSS, SEED, IDEA

SSL hostname validation is enabled by default (AXIS2C-1700). The client will verify that the server's certificate matches the hostname being connected to.

To ensure proper certificate validation:

1. Provide a valid CA certificate file via the SERVER_CERT transport parameter
2. Ensure server certificates include the correct hostname in CN or SAN fields

<transportSender name="https" class="axis2_http_sender">
    <parameter name="PROTOCOL">https</parameter>
    <parameter name="SERVER_CERT">/path/to/ca-bundle.crt</parameter>
</transportSender>

Axis2/C supports HTTP authentication schemes for securing web service communications.

1. Basic Authentication: Credentials are Base64-encoded (not encrypted). Always use with TLS to prevent credential interception.

2. Digest Authentication: More secure than Basic as passwords are hashed, but vulnerable to man-in-the-middle without TLS.

<transportSender name="https" class="axis2_http_sender">
    <parameter name="PROTOCOL">https</parameter>
    <parameter name="HTTP_AUTH_TYPE">Basic</parameter>
    <parameter name="HTTP_AUTH_USERNAME">user</parameter>
    <parameter name="HTTP_AUTH_PASSWORD">password</parameter>
</transportSender>

For HTTPS connections through a proxy (CONNECT tunneling):

<parameter name="PROXY_HOST">proxy.example.com</parameter>
<parameter name="PROXY_PORT">8080</parameter>
<parameter name="PROXY_AUTH_TYPE">Basic</parameter>
<parameter name="PROXY_AUTH_USERNAME">proxyuser</parameter>
<parameter name="PROXY_AUTH_PASSWORD">proxypass</parameter>

Warning: Avoid storing credentials in axis2.xml. Use environment variables or a secrets manager where possible.

When developing Axis2/C services, follow these guidelines:

1. Validate all input data before processing
2. Use parameterized queries when interacting with databases
3. Sanitize output to prevent XSS in any web-facing responses
4. Implement rate limiting for public-facing services
5. Log security events (failed auth, invalid input, etc.)

Axis2/C uses careful buffer management, but service developers should:

• Use snprintf() instead of sprintf() for formatted output
• Always validate buffer sizes before copying data
• Use strncpy() or axutil_strdup() for string operations
• Check return values from memory allocation

/* Safe: Using snprintf with size limit */
char buffer[256];
snprintf(buffer, sizeof(buffer), "Value: %s", user_input);

/* Safe: Using axutil_strdup for heap allocation */
axis2_char_t *safe_copy = axutil_strdup(env, user_input);
if (!safe_copy) {
    /* Handle allocation failure */
}

SOAP faults may contain sensitive information. Follow these guidelines:

1. Production environments: Configure minimal fault details
2. Log detailed errors server-side rather than returning them to clients
3. Use generic error messages for authentication/authorization failures
4. Never include stack traces in production fault responses

In axis2.xml, configure fault handling:

<parameter name="sendStacktraceDetailsWithFaults">false</parameter>

Axis2/C 2.0 introduces HTTP/2 support with pure JSON processing, bypassing the traditional SOAP/XML pipeline. This section covers security considerations specific to HTTP/2 JSON mode.

Axis2/C uses the json-c library for JSON processing. The following security measures are implemented:

To prevent stack exhaustion attacks (similar to CVE-2024-57699 in json-smart):

/* Default: 64 levels of nesting */
#define AXIS2_JSON_MAX_DEPTH 64

Deeply nested JSON like {"a":{"a":{"a":...}}} beyond this limit is rejected.

To prevent memory exhaustion and mitigate CVE-2020-12762 (integer overflow in json-c):

/* Default: 10 MB maximum payload */
#define AXIS2_JSON_MAX_PAYLOAD_SIZE (10 * 1024 * 1024)

Override these limits at compile time if your services require larger payloads:

CFLAGS="-DAXIS2_JSON_MAX_DEPTH=128 -DAXIS2_JSON_MAX_PAYLOAD_SIZE=52428800" ./configure ...

Recommendation: Use json-c 0.15 or later which includes security fixes.

When deploying Axis2/C with Apache httpd, keep httpd updated to address:

Recommendation: Use Apache httpd 2.4.62 or later.

For Android deployments (like the Kanaha camera control example), follow these security practices:

/* DANGEROUS - Command injection vulnerability */
system(intent_command);  /* DON'T DO THIS */

/* SAFE - Use fork()/execvp() */
pid_t pid = fork();
if (pid == 0) {
    char *args[] = {"am", "broadcast", "--user", "0", "-n", ...};
    execvp("am", args);
    _exit(1);
}

Implement defense-in-depth with both Java and C validation:

// Java SecurityValidator (from Kanaha pattern)
public class SecurityValidator {
    private static final String[] PATH_TRAVERSAL = {"..", "//", "\\"};
    private static final String[] INJECTION = {"$(", "`", ";", "|", "&"};

    public static String validate(String input, String paramName) {
        if (input == null || input.isEmpty()) return null;
        String lower = input.toLowerCase();

        for (String pattern : PATH_TRAVERSAL) {
            if (lower.contains(pattern)) return "path traversal";
        }
        for (String pattern : INJECTION) {
            if (lower.contains(pattern)) return "injection attempt";
        }
        if (!input.matches("^[a-zA-Z0-9_\\-\\.\\*]+$")) {
            return "invalid characters";
        }
        return null;  // Valid
    }
}

/* C-side validation (defense in depth) */
if (params->pattern && strstr(params->pattern, "..")) {
    AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI,
        "Security: path traversal detected in pattern");
    return AXIS2_FAILURE;
}

1. HPACK Header Compression: HTTP/2 uses HPACK for header compression. The nghttp2 library handles this securely, but ensure you're using nghttp2 1.50.0 or later.

2. Stream Multiplexing: HTTP/2 multiplexes multiple requests over a single TCP connection. This means multiple concurrent requests from different clients or contexts may share connection state. Service implementations should:

   • Avoid storing request-specific data in connection-level structures
   • Ensure thread-safe access to any shared resources
   • Not assume one-request-per-connection isolation (as in HTTP/1.1)
   • Be aware that a slow or resource-intensive request could affect other streams on the same connection

Axis2/C enforces several size limits to prevent denial-of-service attacks:

Override at compile time:

CFLAGS="-DAXIS2_JSON_MAX_PAYLOAD_SIZE=1048576" ./configure ...  # 1MB limit

Configure socket timeouts to prevent slowloris-style attacks:

/* In code - set read timeout in milliseconds */
axis2_http_socket_read_timeout = 30000;  /* 30 seconds */

When deploying behind Apache httpd with mod_axis2:

# In httpd.conf
MaxRequestWorkers 150
Timeout 60
KeepAliveTimeout 5
MaxKeepAliveRequests 100
LimitRequestBody 10485760  # 10MB
LimitRequestFields 50
LimitRequestFieldSize 4094

For production deployments, build Axis2/C with security hardening flags:

CFLAGS="-fstack-protector-strong -D_FORTIFY_SOURCE=2 -fPIE -Wformat -Wformat-security" \
LDFLAGS="-pie -Wl,-z,relro,-z,now" \
./configure [options]

For development and testing, enable AddressSanitizer to detect memory errors:

./configure --enable-asan [other options]
make

This detects:

• Use-after-free
• Buffer overflows (stack, heap, global)
• Memory leaks
• Double-free

Note: Do not use --enable-asan in production - it adds significant overhead.

The --enable-trace flag enables verbose debug logging. Never enable in production as it may log sensitive data including message contents.

1. Run as non-root: Create a dedicated service account

   useradd -r -s /bin/false axis2
   chown -R axis2:axis2 /usr/local/axis2c

2. File permissions:

   chmod 640 /usr/local/axis2c/axis2.xml      # Config readable by service only
   chmod 600 /path/to/server.key               # Private keys owner-only
   chmod 644 /path/to/ca-bundle.crt           # CA certs world-readable OK
   chmod 750 /usr/local/axis2c/logs           # Logs directory

By default, the standalone server binds to all interfaces (0.0.0.0). For internal services, bind to localhost only:

./axis2_http_server -p 8080 -i 127.0.0.1

For internet-facing deployments, place Axis2/C behind a reverse proxy:

[Internet] → [nginx/Apache] → [Axis2/C on localhost]

Benefits:

• TLS termination at the proxy
• Rate limiting and WAF rules
• Request filtering
• Connection limits

Example nginx configuration:

location /axis2/ {
    proxy_pass http://127.0.0.1:8080/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;

    # Rate limiting
    limit_req zone=axis2_limit burst=20 nodelay;

    # Size limits
    client_max_body_size 10m;
}

For a working example of these security patterns applied to an Android camera control system, see the Kanaha project's security documentation:

• Kanaha SECURITY.md - mTLS configuration, audit logging, Apache httpd hardening, user-agent filtering, certificate revocation procedures

Note: Kanaha is an independent project (GPLv3 licensed due to OpenCamera dependency) and is not affiliated with Apache Software Foundation. It demonstrates production deployment patterns for the CameraControlService sample in samples/user_guide/camera-control-service/.

• Authentication failures (username, source IP, timestamp)
• Authorization failures
• Invalid input attempts
• Service errors (without sensitive details)
• Connection anomalies

Never log these values:

• Passwords or authentication tokens
• Credit card numbers or PII
• Full SOAP message bodies in production
• Private keys or certificates

If logging user-supplied data, sanitize newlines and control characters:

/* Remove newlines to prevent log injection */
char *sanitized = axutil_strdup(env, user_input);
for (char *p = sanitized; *p; p++) {
    if (*p == '\n' || *p == '\r') *p = ' ';
}
AXIS2_LOG_INFO(env->log, AXIS2_LOG_SI, "User input: %s", sanitized);

Building with --enable-trace enables verbose logging that may include message contents. This flag must never be used in production builds.

# OpenSSL
openssl version

# libxml2
pkg-config --modversion libxml-2.0

# json-c
pkg-config --modversion json-c

# nghttp2
pkg-config --modversion libnghttp2

• Verify package checksums when downloading dependencies
• Use distribution packages where possible (apt, yum) for automatic security updates
• Subscribe to security mailing lists for critical dependencies

Axis2/C maintains a monthly CVE checker via GitHub Actions (.github/workflows/cve-check.yml) that:

1. Queries NVD for CVEs affecting Axis2/C dependencies
2. Creates GitHub issues when new CVEs are discovered
3. Triggers updates to the minimum versions table above

Responsibility Chain:

┌─────────────────────────────────────────────────────────────┐
│  Axis2/C (Library) - This Repository                        │
│  ─────────────────────────────────────────                  │
│  • Monthly CVE checker monitors dependencies                │
│  • Maintainers update SECURITY.md minimum versions          │
│  • Advisory: "Use OpenSSL 3.2.1+ for CVE-XXXX"              │
│                          │                                  │
│                          ▼                                  │
│  All downstream applications see the advisory               │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│  Downstream Applications (e.g., Kanaha)                     │
│  ─────────────────────────────────────                      │
│  • OWASP Dependency-Check scans actual build artifacts      │
│  • CI fails if critical CVEs exist in shipped binaries      │
│  • Developers rebuild deps and release patched versions     │
└─────────────────────────────────────────────────────────────┘

Why this model:

• Axis2/C is distributed as source code (no binaries since 2009)
• Library maintainers track CVEs and advise minimum versions
• Application maintainers (who ship binaries) act on CVE findings
• Separation of "awareness" (library) from "action" (application)

Axis2/C supports WS-Security through the Apache Rampart/C module, which provides:

• XML Signature (signing SOAP messages)
• XML Encryption (encrypting SOAP messages)
• Username Token authentication
• SAML token support
• Security policy enforcement

Rampart/C is a separate project. See: https://axis.apache.org/axis2/c/rampart/

Note: XML Signature is vulnerable to signature wrapping attacks if not properly configured. Ensure you validate the signed elements match the elements being processed.

Before deploying Axis2/C in production:

• Use Guththila parser (default) or verify libxml2 security flags
• Configure SSL/TLS with valid certificates
• Disable SSL compression and weak protocols
• Enable hostname validation
• Implement input validation in all services
• Configure appropriate logging
• Disable stack traces in SOAP faults
• Apply principle of least privilege to service accounts
• Keep Axis2/C and dependencies updated

• Build with hardening flags (-fstack-protector-strong, -D_FORTIFY_SOURCE=2, etc.)
• Run as non-root user with minimal permissions
• Bind to localhost if not internet-facing
• Place behind reverse proxy for public services
• Configure appropriate timeout values
• Verify all dependencies are at minimum secure versions

• Use json-c 0.15 or later
• Verify JSON depth and payload limits are appropriate for your services
• Update Apache httpd to 2.4.62 or later
• Use nghttp2 1.50.0 or later
• Implement input validation for all JSON fields
• For Android: Use fork()/execvp() instead of system() for IPC

To report security vulnerabilities in Apache Axis2/C, please follow the Apache Security Team guidelines:

https://www.apache.org/security/

Do not report security issues via public GitHub issues or mailing lists.

• OWASP XML External Entity Prevention Cheat Sheet
• CWE-611: Improper Restriction of XML External Entity Reference

• OWASP Transport Layer Protection Cheat Sheet
• CWE-295: Improper Certificate Validation

• json-c Security Vulnerabilities (CVE Details)
• CVE-2020-12762: json-c Integer Overflow

• Apache HTTP Server 2.4 Vulnerabilities
• Apache HTTP Server Security in 2025 (Stack Watch)

• nghttp2 Security Advisories
• HTTP/2 (RFC 7540) Security Considerations

For HTTP/2 JSON web services (Axis2/C 2.0.0+), a dedicated penetration test script is available:

# Run against deployed services
./test/security/h2_penetration_test.sh https://localhost:8443

# Tests include:
# - Deeply nested JSON (stack exhaustion)
# - Huge string values (memory exhaustion)
# - Malformed JSON variants
# - Integer overflow conditions
# - Concurrent request handling
# - HTTP/2 header overflow

Build and deploy services with AddressSanitizer for memory error detection:

./configure --enable-asan --enable-http2 --enable-json ...
make && make install

When running Apache httpd (built from source) as a systemd service with ASAN-enabled Axis2/C modules, add these environment variables to /etc/systemd/system/apache2-custom.service:

[Service]
Environment="LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.8"
Environment="ASAN_OPTIONS=detect_leaks=1:log_path=/tmp/asan_apache:abort_on_error=0:halt_on_error=0"

Then reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart apache2-custom.service

The ASAN options:

• detect_leaks=1: Enable memory leak detection
• log_path=/tmp/asan_apache: Write ASAN reports to files (with PID suffix)
• abort_on_error=0: Don't abort on first error (log all errors)
• halt_on_error=0: Continue execution after errors (for penetration testing)

Check ASAN output after running tests:

cat /tmp/asan_apache.*

The following stress tests were performed against BigDataH2Service and FinancialBenchmarkService with ASAN enabled. All tests passed with no memory errors detected:

All tests completed with zero ASAN errors detected.

The following deprecated features have been removed to reduce attack surface:

• --enable-ntlm / --enable-heimdal / --enable-libntlm
• --enable-tcp
• --enable-cgi
• --enable-libcurl

Security hardening commits are reviewed using Google Gemini AI for:

• Memory safety issues (buffer overflows, use-after-free)
• Input validation gaps
• SSL/TLS configuration weaknesses
• Error handling issues

1. TLS 1.2+ required (TLS 1.0/1.1 completely disabled)
2. Strong cipher suites configured (AEAD with forward secrecy)
3. JSON payload size limits enforced in HTTP/2 streaming mode
4. Improved error messages include source context for debugging

Apache Axis2/C includes comprehensive fuzz testing infrastructure for integration with OSS-Fuzz, Google's continuous fuzzing service for open source projects.

cd /path/to/oss-fuzz
sudo python3 infra/helper.py build_fuzzers --sanitizer address axis2c /path/to/axis-axis2-c-core
sudo python3 infra/helper.py run_fuzzer axis2c fuzz_xml_parser -- -max_total_time=60

For complete setup instructions, build details, and troubleshooting:

• OSS-FUZZ.md - Comprehensive fuzzing guide
• JSON_HTTP11_VS_HTTP2.md - JSON fuzzer architecture details